与http协作的web服务器
1、虚拟主机
一台web服务器可以搭建多个独立域名的web网站，也可以作为通信线路上的中转服务器提升传输效率。比如web托管服务供应商可以用一台服务器为多个不同域名的客户提供服务，这是利用了虚拟主机（virtual host，又称虚拟服务器）的功能。在发送http请求时，必须在Host首部内完整指定主机名或域名的URI，以确定要请求的web网站。
2、代理
通信数据转发程序：代理、网关、隧道、中继。
如下图，转发“客户端”和“服务器”之间的数据，使用代理服务器可以利用其缓存技术减少网络带宽流量，也可以控制内部对特定网站的访问。每次通过代理服务器转发请求或响应时，会追加写入via首部信息。代理不改变请求的URI，它直接发送给前方的目标服务器。转发时不对报文做任何加工则为透明代理，否则为非透明代理。
代理服务器或客户端本地保存的资源副本称为缓存，缓存服务器是代理服务器的一种。即使存在缓存，也会因为缓存的有效期、客户端的要求等因素，向服务器确认资源的有效性。
正向代理：客户端将请求发给代理服务器，由代理服务器获得目的服务器的数据后将数据再发给客户端。所以客户端除了目的服务器之外，还需要设置代理服务器的地址，比如在浏览器中输入目的网址后，还需要在设置中设置代理服务器地址。正向代理是为客户端提供代理服务，需要客户主动设置代理服务器的信息，其一般用在客户端无法访问到目的或者加速访问服务的情况。
反向代理：反向代理服务器也是位于用户与实际服务器之间，但对于用户而言，反向代理服务器就相当于目标服务器，在浏览器中直接输入反向代理服务地址就能访问数据，不需要实际服务器地址。反向代理服务器通常用来作为Web加速，比如负载均衡，所以代理服务实际上是为后端的服务器提供的，我们把为客户提供服务的代理称为正向代理，所以为后端提供代理称为反向代理。
3、反向代理和负载均衡
上面提到的反向代理，nginx就提供了这种反向代理的功能，并提供了SLB（服务器负载均衡）策略，比如轮询（请求被顺序分配）、加权（权重高的被分配到的请求越多）、ip_hash（按访问IP的哈希来分配，这样每个访客固定访问一个服务器，解决session问题）、最小连接（最少连接的服务器优先分配请求）、最短响应时间（按照服务器的响应时间来分配请求，属于第三方策略）等。
负载均衡除了通过反向代理实现外，还有重定向、DNS负载均衡等，当然这些主要针对的是HTTP Web通信。以下内容转载自 infoQ：负载均衡概述及优缺点对比：
①、重定向负载均衡
如下所示，每次请求，都需要两次 http 通信，延时较长，而且对外暴露了服务器地址，不安全：
②、DNS负载均衡
如下所示，对于每次请求，DNS 解析到的 IP 地址不同，从而实现了负载均衡。DNS是一个分布式网络服务，一般不必担心它的性能问题，许多DNS还支持基于地理位置的域名解析，将域名解析成距离用户地理最近的一个服务器地址，以加快访问速度，所以这种负载均衡方式也较常用。这种方式的缺点是DNS负载均衡的控制权在域名服务商手里，有的DNS负载均衡策略采用的是简单的轮询算法，不能区分服务器之间的差异，个人可能无法做出过多的改善和管理。
使用该方式的另外一个缺点是，客户中可能会缓存DNS地址，更改了某个地址或者某个服务出错的话可能不会那么快改变为正常的服务地址。所以实际使用该方式的时候，会使用两层反向代理，在应用服务器之前有一层反向代理即负载均衡服务来获得指定的服务地址，DNS 负载均衡用于第一层负载均衡，解析出来的是第二层负载均衡服务器的地址，若某一个服务出错，在第二层负载均衡可以感知到然后将其从服务集群中去掉。使用这种方式的两层反向代理，应用服务器集群还可以放到内网中去，更加安全。
③、应用层反向代理
如下所示，应用层反向代理相当于是一个转发服务器（七层转发），它通过分析用户发送的HTTP包来将请求进行转发，nagix 本身的反向代理服务器，就有该功能。因为处理的是应用层的http数据，所以对对反向代理服务器压力很大，一般应用服务器最多是几十台，因此，大一些的网站不会使用这种模式。新的nginx增加了支持四层转发的功能，所以nginx也支持传输层反向代理，直接对TCP数据进行转发，比七层转发性能要高。
④、IP层（网络层）反向代理负载均衡
如下所示，负载均衡服务器将客户发来的数据包的目标地址修改为后台服务的地址，后台集群服务器需要将自己的网关设置为负载均衡服务器的地址，这样后台服务就会将响应数据先转发给负载均衡服务器，负载均衡服务器收到数据包后将源地址修改为自己IP地址后发送给客户。IP负载均衡在内核进程完成数据分发（通过修改TCP / IP协议栈，在IP层截取和改写IP报文），所以处理能力比应用层转发要高，而且这种方式的应用服务器集群在内网中，更安全。使用这种方式的缺点是请求和响应网络数据都通过负载均衡服务器，尤其是一般响应数据会比较大，负载均衡的网络出口带宽压力会比较大。
⑤、数据链路层反向代理负载均衡
如下所示，负载均衡服务器将请求的MAC地址修改为应用服务地址，这样响应数据会直接返回到用户那里。由于数据报文中的目的IP地址是负载均衡服务器地址，所以需要把应用服务器集群中所有主机的虚拟IP地址（VIP, Virtual IP Address）配置成与负载均衡服务器的IP一样。这种负载均衡方式的性能很高，一些大型互联网应用会选择这种方式。使用这种方式的话，负载均衡服务器应该与应用服务器集群在同一个子网中，另一个就是必须保证所有的后台服务器的虚拟IP地址与均衡器IP相同（虚拟IP需由系统管理员介入配置，而且，对服务器进行虚拟 IP 的配置并不是在任何情况下都可行的，尤其是当有好几个服务共用一台物理服务器的时候）。
⑥、IP层反向代理负载均衡的高效模式
实际上IP层负载均衡也可以做到像链路层负载均衡那样的单次转发，方法是负载均衡服务收到客户发来的数据包后对其不做改变，而是将其放到一个新的数据包中来发送给后台服务（新数据包的目标地址为后台服务地址）。经过三层路由器的转发，后台服务收到数据包后，在接收入口处设计一个针对性的拆包机制，把由负载均衡器自动添加的那层 Headers 扔掉，还原出原来的数据包来进行使用。这种封装老的数据包到新的数据包的传输方式叫做“IP 隧道”（IP Tunnel）传输。因为服务使用的是拆包后的原数据包，且其中的源IP地址没变，所以响应数据会从服务直接发送给客户，如下所示：
这种负载均衡模式的优点就是负载均衡服务不用再二次转发，而且而且由于 IP 隧道工作在网络层，所以可以跨越 VLAN。 其缺点是：封装和拆装数据包会降低一些效率；另一个缺点是服务器必须支持“IP 隧道协议”（IP Encapsulation），就是它得学会自己拆包扔掉一层 Headers，这个其实并不是什么大问题，现在几乎所有的 Linux 系统都支持 IP 隧道协议。
⑦、三次握手与负载均衡
上面所说的几种负载均衡方式，“数据链路层反向代理负载均衡”的效率是最高的。对于三次握手的通信，是负载均衡服务器先与用户完成三次握手通信后再将用户数据发送到后台服务，还是每次握手的数据通信也会发送到后台服务来处理，这块还不太清楚。
⑧、各负载均衡解决方案对比
Nginx：支持七层和四层转发来实现负载均衡。
Haproxy：专业负载均衡软件，与Nginx一样支持七层和四层转发，但性能比Nginx要高。
LVS：Linux Virtual Server，基于Linux操作系统实现负载均衡，使用内核转发，相比Nginx和HaProxy这种应用实现性能要高很多。其有三种模式：NAT、IP Tunnel、DR，分别对应前面所说的“IP层反向代理负载均衡”、“IP层反向代理负载均衡的高效模式”、“数据链路层反向代理负载均衡”。linux内核2.6之前的版本中使用LVS的话需要重新编译内核中，2.6之后的LVS已经成为内核的一部分。同nginx一样，LVS也提供了多种负载调度算法，如轮询、加权轮询、最少连接等。LVS所在的服务器是Linux，但后台服务器可以是任何支持TCP/IP的操作系统，包括Linux和Windows。LVS性能虽然比Nginx高，但对于应用的配置灵活性和功能性不如Nginx，比如可配置各种规则对Http请求进行分流，动静分离等，所以可以在LVS后配置多台Nginx来进行一些HTTP自定义操作，然后再是应用服务器。
SLB（Server Load Balancer）：如果使用的是阿里云服务，那么就可以使用阿里云的SLB来支持负载均衡，其使用LVS或Tengine（七层转发）来实现负载均衡。
Windows Server 内置NBL负载均衡功能：原理和LVS的DR相似，但是相比更加暴力，请求使用广播方式，同一个交换机下RS都将受到请求，RS通过一致性算法确认自己改处理请求还是丢弃请求。
F5：专业的硬件负载均衡器，价格昂贵。
⑨、keepalived
Keepalived是Linux下一个轻量级别的高可用解决方案，起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，如果某个服务器节点出现故障，Keepalived将检测到后自动将节点从集群系统中剔除。Keepalived也可以用来检测LVS服务器的健康状况，当主LVS挂掉后，Keepalived使用从LVS来提供服务。我们如果使用nginx来搭建负载均衡服务的话，就可以使用keepalived来提供服务的高可用：提供两个nginx，一个master，一个slave，slave是备用nginx服务，如果 nginx master出现宕机，keepalived则会将服务切到 nginx slave上，保证业务不受影响。
⑩、BGP、VPS、云主机、云服务器
在购买云主机或vps等主机产品时，会涉及到线路选择，而在线路选择中，有时候会看到其中有BGP机房。BGP是边界网关协议（Border Gateway Protocol）的简称，主要用于互联网AS（自治系统）之间的互联。目前BGP的最主要功能在于控制路由的传播和选择最好的路由，以保证网通、电信用户的高速访问。一般的IDC机房分为单线（移动或联通）机房、双线机房（移动和联通）和BGP机房，选择BGP机房可以实现网站在各运营商线路之间实现互联互通，做到使用不同互联运营商（移动、联通、电信）的用户访问你的网站都会很快。
云主机需要自主安装操作系统，云服务器则预装了操作系统。VPS（Virtual Private Server）是虚拟专用服务的意思，其有自己的独立操作系统，独立ip，但这都是虚拟化的（一台主机被分割成多个VPS来使用）。VPS与云服务器相比的话，虽然二者都是虚拟化产品，但VPS是使用的传统虚拟技术实现的（性能要低），而云服务器是基于云计算技术来实现虚拟化的（性能高），可以把云服务器当成真正服务器对待，其性能比VPS要高，所以VPS适合用来部署小型网站，而且其价格比云服务器要便宜。VPS的另一个缺点是可扩展性不高，如果想要升级VPS的配置的话，可能需要将当前VPS停机一段时间。
4、CDN
CDN即内容分发网络，其核心理念就是将内容缓存在用户附近来使用，CDN服务就是缓存服务，远端服务的内容会复制一份放到CDN服务上：
下面是DNS域名解析的过程：
1）用户在浏览器输入www.baidu.com，浏览器在本机的C:\Windows\System32\drivers\etc\hosts文件中查找是否有对应IP
2）本机hosts上没有的话，会向ISP LocalDNS发起请求，若LocalDNS的缓存中有记录，则直接返回给用户
3）LocalDNS上没有缓存的话，LocalDNS会向RootDNS发起请求，询问.com的域名服务器地址（又称为域名的授权服务器），RootDNS会向其发送.com的域名服务器列表，LocalDNS会选择列表中的一个去请求baidu.com的域名解析服务器（一个或多个，这些域名解析服务器称为权威DNS服务器），LocalDNS收到回复后会在回复中选取一台域名解析服务器向其发送域名解析请求，域名解析服务器会将域名对应IP地址发送给LocalDNS
4）LocalDNS将获得的IP地址发送给浏览器
使用CDN的话，会在上面第三步完成后，将获得的域名和地址发送给CDN专用DNS（又称智能调度DNS）来获得CDN节点地址（CDN缓存地址），智能调度DNS会根据一定的算法和策略将最合适的CDN节点发送给LocalDNS，然后LocalDNS会将CDN节点地址回应给浏览器，浏览器向CDN节点请求数据，如果CDN节点上缓存了数据的话会直接发送给浏览器，没有的话先向实际后台服务请求数据后备份到本服务上然后发送给浏览器。
CDN适用于静态内容（视频以及网站的静态资源，如图片、html、css、js等），不适用动态的内容，用户动态的实时交互数据是难以缓存的，例如一些频繁修改的数据库表单内容等。
5、网关
网关工作机制与代理类似，但网关提供了http协议和其它协议之间的转换。可以将网关可以分为“协议网关”和“资源网关”。
“协议网关”（如下图）主要有：http/ftp输入转换网关、http/pop网关、https/http安全加速器网关（通常作为拦截网关或反向代理使用，这种网关通常都包含专用的解密硬件，其解密速度比普通的https服务器要快，这样也可以减轻web服务器的负荷，网关与web服务器之间的网络应该确保是安全的，比如是受保护的内部LAN）、http/https输入安全网关（一个组织可以通过网关对普通的http请求加密，以提供额外的隐私和安全保护）。
资源网关主要有“数据库网关”和“应用程序服务器”（如下图）。数据库网关：客户端通过http协议向服务器发送请求，当请求数据库资源的时候服务器与网关进行交互以获取资源，网关可以连接数据库，向数据库发送查询语句。应用程序服务器：将目标服务器和网关结合在一起的服务器，应用程序服务器（作为目标服务器）与客户端通过http通信，（作为网关）并与服务器端的应用程序相连。通用网关接口(Common Gateway Interface, CGI)是一个流行的应用程序网关API，CGI在Web上广泛用于数据库査询、信用卡结算处理、动态HTML等任务，CGI应用程序独立于服务器，几乎可以用任意语言来实现。
6、隧道
Web隧道允许用户通过HTTP连接发送非HTTP流量，这样就可以在HTTP上捎带其他协议数据了。使用Web隧道最常见的原因就是要在HTTP连接中嵌入非HTTP流量，这样，这类流量就可以穿过只允许Web流量通过的防火墙了。HTTP 隧道的一种常见用途是通过 HTTP 连接承载加密的安全套接字层（SSL，Secure Sockets Layer） 流量， 这样 SSL 流量就可以穿过只允许 Web 流量通过的防火墙了。
比如，在一个网络中，防火墙禁止端口443上的连接，因此网络中的用户无法访问使用HTTPS协议的网站。但是，防火墙允许端口80上的连接。网络中的用户想要访问该服务器有两种方法：一种是使用http/https输入安全网关，一种是通过HTTP隧道。使用网关的方法有三个缺点：客户端到网关之间的连接是普通的非安全HTTP；客户端无法对远端服务器执行SSL客户端认证；网关要支持完整的SSL实现。使用隧道的话SSL流量被封装到一条HTTP报文中，并通过HTTP端口80上的连接发送， 最后被解封为普通的SSL流量。 使用隧道协议的流程是客户端发送一条CONNECT请求给网关请求打开一条TCP连接（在这里，打开的是到目标主机的标准SSL端口443的连接），一旦建立了TCP连接，网关就会发送一条HTTP 200 Connection Established响应来通知客户端；此时，隧道就建立起来了。如下图：
前面描述了一条SSL隧道，其中的SSL流量是在一条HTTP连接上发送的，通过CONNECT方法可以与使用任意协议的任意服务器建立TCP连接。一些喜欢捣乱的用户可能会通过本打算用于SSL的隧道越过公司防火墙传递因特网游戏流量，而恶意用户可能会用隧道打开Telnet会话，或用隧道绕过公司的E-mail扫描器来发送E-mail。为了降低对隧道的滥用，网关应该只为特定的知名端口，比如HTTPS的端口443打开隧道。
7、中继
中继负责处理HTTP中建立连接的部分，然后对字节进行盲转发。某些简单盲中继实现中存在的一个常见问题是，它们无法正确处理Connection首部，所以有潜在的挂起keep-alive连接的可能。
如下图，Web客户端向中继发送了一条包含Connection: Keep-Alive首部的报文，如果可能的话要求建立一条keep-alive连接。客户端等待响应，以确定它要求建立keep-alive信道的请求是否被认可了。中继收到了这条HTTP请求，但它并不理解Connection首部，因此会将报文一字不漏地沿着链路传递给服务器。但Connection首部是个逐跳首部，只适用于单条传输链路，是不应该沿着链路传送下去的。这会导致客户端和服务器建立了长连接后中继器却不知道，它会在收到原始服务器的所有数据后转发给客户端，然后等待原始服务器关闭连接，这样，中继就会挂起，客户端再次在这条连接上发送请求的话，中继不会去理睬。
要为某个特定目标构建简单的HTTP中继，一定要特别注意其使用方法。对任何部署来说，都要非常认真地考虑使用真正的、完全遵循HTTP的代理服务器。
以上内容转载和参考自：代理、网关与隧道，https://blog.csdn.net/sjailjq/article/details/82287345
前端学HTTP之网关、隧道和中继，https://www.cnblogs.com/xiaohuochai/p/6180941.html
