web客户端请求是怎么到达服务器的

本篇内容介绍了“web客户端请求是怎么到达服务器的”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

1、数据包

一、HTTP请求和响应步骤

http请求全过程

请求

响应

以上完整表示了HTTP请求和响应的7个步骤，下面从TCP/IP协议模型的角度来理解HTTP请求和响应如何传递的。

2、TCP/IP概述

我们以RFC 1180中的图作为参考

上图展示了四层TCP/IP协议图，其中network  applications是应用程序，属于应用层;TCP和UDP主要是传输数据，属于传输层，TCP确保端对端的可靠传输并尽量确保网络健康运行，而UDP是简单不可靠传输;IP主要解决路由问题，属于网络层;ARP是网络地址转换，主要用来转换IP地址和MAC地址，介于数据链路层和网络层之间，可以看成2.5层;ENET在这里是数据链路层，网卡驱动属于这一层，主要做具体的介质传输，前面示例中的广告请求抓包就是在数据链路层抓取。

值得注意的是，ARP在linux系统里属于网络层，而在RFC里是介于数据链路层和网络层之间。在《TCP/IP详解》一书里，ARP被放到了数据链路层。当解决实际问题的时候，我们应该把ARP放到网络层。

上图给出使用TCPCopy在不同层发包的使用方法。如果TCPCopy从数据链路层发包，由于没有享受到ARP服务，用户需要在使用TCPCopy的时候额外加上MAC地址;而如果TCPCopy从IP层发包，则无需指定MAC地址。

本课程主要讲述TCP相关案例，没有特殊说明的话，TCP特指传输层的TCP。

3、什么是TCP

TCP即传输控制协议，是一种面向连接的、可靠的、基于字节流的通信协议。TCP的主要工作是定义端口标识应用程序的身份，实现端对端的可靠通信，并进行拥塞控制，防止互联网崩塌。

TCP有如下关键特性：

由于TCP是面向连接的协议，所以是一种有状态的协议，而有状态的协议往往比较复杂，因此TCP学习起来也比较困难。

通过状态图来查看一下TCP状态的复杂性：

上图展示了错综复杂的TCP状态图，然而现实更加复杂。

现实中的TCP状态图其实是这样的：

图中，不仅SYN_RCVD状态能够收到reset数据包(图中RST，reset数据包是重置连接的数据包，可以使TCP状态瞬间变为CLOSED状态，而CLOSED状态是无法追踪的)，而且FIN_WAIT1、FIN_WAIT2、ESTABLISHED、SYN_SENT和CLOSE_WAIT都能被reset数据包打回到CLOSED状态。不仅如此，TCP状态还受到超时的影响。例如Linux系统，一旦连接处于FIN_WAIT_2，在60秒内(默认)如果没有接收到对端的FIN数据包，系统会把此连接状态FIN_WAIT_2直接变到CLOSED状态。虽然Linux这样做是为了防止攻击，但这种超时就干掉连接状态的做法，很可能误杀了很多正常连接，从而使问题更加捉摸不定。

在互联网领域，很多诡异的问题跟TCP状态有关系，课程后续会有较多案例来讲述这些灵异问题。

4、端口

当我们去连接服务器程序时，需要指明服务器端口。为什么需要端口呢?因为系统是通过端口来区分不同应用程序，TCP通过端口找到上层应用。

需要注意的是，端口号是有限的，端口号最大为65535，能够利用的端口数量随配置而定。例如在压力测试过程中，一台机器可以利用的TCP端口是有限的，能够利用的连接(客户端端口，客户端IP，服务器应用端口，服务器IP地址)是有限的。为了解决这个问题，可以配置多IP地址来扩大可用连接数量。系统支持同一个端口，不同的IP地址来绑定不同的应用。Linux高版本系统下，在绑定同一个IP地址的情况下，我们还可以利用REUSEPORT机制使不同应用程序共享同一个监听端口，这对高性能服务器开发是非常有用的。我们开发的数据库中间件cetus就利用这个机制来解决短链接风暴的问题。

5、IP

网络层的主要工作是定义网络地址，区分网段，子网内MAC寻址，对不同子网的数据包进行路由。IP的主要作用就是在复杂的网络环境中将数据包发给最终的目标地址。

IP是面向无连接的，是无状态的协议。IP为什么被设计成无状态呢?

1. 无状态协议处理简单

2. 通信之前无需建立连接

3. TCP已经面向连接服务了，IP层可以委托TCP来解决面向连接的问题

4. 由于不带有状态，互联网路由起来更加自由，容错性也更强

值得注意的是，现实中的IP层往往都带有安全过滤，甚至有些路由器，防火墙等中途设备还会干涉应用(例如通过reset数据包来干涉TCP会话)，为了更好的做安全检测，IP层还增加了connection  tracking，在无状态协议上面来追踪上层连接。这种方式提高了安全性，但有时也会带来新的问题，我们后面有案例具体讲述connnection  tracking带来的坑的故事。

6、TCP Socket

应用程序通过TCP socket接口来调用TCP服务，从而达到传递数据的目的。每一个TCP socket会被绑定到一个端口，TCP  socket双向都可以通信，在发送数据的同时，还可以接收数据。

值得注意的是，应用程序发送完数据，只代表通过TCP  socket委托给TCP的工作已经完成，不代表发送给对端完毕，应用发送数据和TCP传输数据不是同步的。

7、How TCP/IP Works

当用户通过TCP socket接口发送请求后，TCP协议模块接管了请求传递，TCP先把请求拆分成一个个更小的数据分段(假设TCP  offload没有开启的情况下)，通过IP层发送出去。在IP层，这些数据分段会被封装成IP数据包，通过数据链路层发送给互联网(见下图)。这些数据包经过互联网的多个路由器到达目的地。由于IP网络是无状态的协议，每一个数据包走的路径可能不一样，而且到达的顺序也有可能不一样，这就要求对端的TCP需要重新组装数据包，以确保向应用层传递的数据是用户能够识别的用户请求，这样服务器应用程序就可以处理用户发起的请求了。

下图中，假设用户请求拆分成两个IP数据包

第一个IP数据包可能经过A，B，C，G，如下图。

第二个数据包可能经过A，B，E，G(在B点选择了E节点，导致路径不同)，如下图。

导致数据包在B节点走向不同路径的原因可能有很多种，例如C节点暂时不如E节点通畅或者临时发生了网络拥塞，这与在高速道路驾驶的原理差不多。

由于网络环境多变，还可能第二个数据包先到达服务器，这时TCP会负责处理out of  order的情况;如果网络传递过程中，某一个路由器由于过于繁忙，把第一个数据包丢了，那么客户端的TCP会负责重传第一个数据包，确保服务器端的TCP能够不会因为丢包而收不到第一个数据包。

如果用户请求内容很大，如上传一个大文件，就会被拆分成大量数据分段，而TCP传输这些数据分段的时候，往往还会考虑整个互联网能够接收的程度和对方能够接收的程度，发送数据过于贪婪不仅会连累整个互联网，对方也未必能够接收得了，而且还可能使自己速度更慢，这有点像道路驾驶一样，不能过于自私，遵守一定的交通规则才能使道路通畅。在互联网传输数据方面，这些交通规则算法就是赫赫有名的网络拥塞控制算法，而对方能否接收得了，则通过发送窗口的方式进行控制。总体来说，一次发送数据的大小是根据对方的接收窗口大小和拥塞控制算法来综合决定的。

从上面可以看出，IP负责在互联网传输数据，而TCP负责数据传输可靠并且尽量使网络健康运行，两者合作完成了请求的传递，这也是互联网应用工作的普遍方式。

需要注意的是，TCP负责跟TCP进行交互，应用层无需去实现TCP的功能，只需要委托给TCP来完成数据传输，这种隔离的方式给应用层的开发/运维/测试带来了方便，另外，当出现TCP相关问题时，解决问题的难度也大大增加。

8、TCP经验知识

在多年实战过程中，我们发现以下TCP经验对工作很有帮助。总结如下：

1. 距离越远，延迟越大，重传概率越大

2. 网络状况好坏，直接影响应用程序性能

3. 不同环境，采用不同的拥塞算法

4. 拥塞控制算法是互联网的精华，是互联网大获成功的关键因素之一

5. TCP是有状态协议，采用异步处理

6. 抓包分析是找到TCP相关问题根本原因的利器

7. TCP客户端和TCP服务器端之间的交互，是应用层所有应用公共的交互部分，理解了这部分原理，可以解决大量TCP相关问题。

9、IP经验知识

在IP经验知识方面，我们大致总结如下：

1. 数据包选择路径不是固定的，到达的顺序也可能是乱序的

2. 安全过滤，坑多的地方

3. 无状态协议，简化互联网架构，是互联网大获成功的关键因素之一

4. IP层对TCP传递过来的数据包很少分片处理

5. 中途设备不仅仅具备路由功能，而且还会干涉TCP会话(灵异问题的温床)

“web客户端请求是怎么到达服务器的”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！