一次完整的HTTP事务是怎样一个过程？_属于一次完整的http事务是一个过程-CSDN博客

本文链接：https://blog.csdn.net/2401_85013081/article/details/138879380

收集整理了一份《2024年最新物联网嵌入式全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升的朋友。

如果你需要这些资料，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

抓包分析：

① 号包，这个是那台虚拟机在广播，要获取192.168.100.254（也就是网关）的MAC地址，因为局域网的通信靠的是MAC地址，它为什么需要跟网关进行通信是因为我们的DNS服务器IP是外围IP，要出去必须要依靠网关帮我们出去才行。

② 号包，这个是网关收到了虚拟机的广播之后，回应给虚拟机的回应，告诉虚拟机自己的MAC地址，于是客户端找到了路由出口。

③ 号包，这个包是wget命令向系统配置的DNS服务器提出域名解析请求（准确的说应该是wget发起了一个DNS解析的系统调用），请求的域名www.linux178.com,期望得到的是IP6的地址（AAAA代表的是IPv6地址）

④ 号包，这个DNS服务器给系统的响应，很显然目前使用IPv6的还是极少数，所以得不到AAAA记录的

⑤ 号包，这个还是请求解析IPv6地址，但是www.linux178.com.leo.com这个主机名是不存在的，所以得到结果就是no such name

⑥ 号包，这个才是请求的域名对应的IPv4地址（A记录）

⑦ 号包，DNS服务器不管是从缓存里面，还是进行迭代查询最终得到了域名的IP地址，响应给了系统，系统再给了wget命令，wget于是得到了www.linux178.com的IP地址，这里也可以看出客户端和本地的DNS服务器是递归的查询（也就是服务器必须给客户端一个结果）这就可以开始下一步了，进行TCP的三次握手。

2.发起TCP的3次握手

拿到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024 < 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序（本文就以Nginx为例），最终建立了TCP/IP的连接。

如下图：

1） Client首先发送一个连接试探，ACK=0 表示确认号无效，SYN = 1 表示这是一个连接请求或连接接受报文，同时表示这个数据报不能携带数据，seq = x 表示Client自己的初始序号（seq = 0 就代表这是第0号包），这时候Client进入syn_sent状态，表示客户端等待服务器的回复

2） Server监听到连接请求报文后，如同意建立连接，则向Client发送确认。TCP报文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到对方下一个报文段的第一个数据字节序号是x+1，同时表明x为止的所有数据都已正确收到（ack=1其实是ack=0+1,也就是期望客户端的第1个包），seq = y 表示Server 自己的初始序号（seq=0就代表这是服务器这边发出的第0号包）。这时服务器进入syn_rcvd，表示服务器已经收到Client的连接请求，等待client的确认。

3） Client收到确认后还需再次发送确认，同时携带要发送给Server的数据。ACK 置1 表示确认号ack= y + 1 有效（代表期望收到服务器的第1个包），Client自己的序号seq= x + 1（表示这就是我的第1个包，相对于第0个包来说的），一旦收到Client的确认之后，这个TCP连接就进入Established状态，就可以发起http请求了。

看抓包截图：

⑨ 号包这个就是对应上面的步骤 1）

⑩ 号包这个对应的上面的步骤 2）

号包这个对应的上面的步骤 3）

TCP 为什么需要3次握手？

举个例子：

假设一个老外在故宫里面迷路了，看到了小明，于是就有下面的对话：

老外： Excuse me，Can you Speak English?

小明： yes 。

老外： OK,I want …

在问路之前，老外先问小明是否会说英语，小明回答是的，这时老外才开始问路

2个计算机通信是靠协议（目前流行的TCP/IP协议）来实现,如果2个计算机使用的协议不一样，那是不能进行通信的，所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协议，协商完成后就可以进行通信了，当然这样理解不是那么准确。

为什么HTTP协议要基于TCP来实现？

目前在Internet中所有的传输都是通过TCP/IP进行的，HTTP协议作为TCP/IP模型中应用层的协议也不例外，TCP是一个端到端的可靠的面向连接的协议，所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。

3.建立TCP连接后发起http请求

进过TCP3次握手之后，浏览器发起了http的请求（看第包），使用的http的方法 GET 方法，请求的URL是 / ,协议是HTTP/1.0

下面是第12号包的详细内容：

以上的报文是HTTP请求报文。

那么HTTP请求报文和响应报文会是什么格式呢？

起始行：如 GET / HTTP/1.0 （请求的方法请求的URL 请求所使用的协议）

头部信息：User-Agent Host等成对出现的值

主体

不管是请求报文还是响应报文都会遵循以上的格式。

那么起始行中的请求方法有哪些种呢？

GET: 完整请求一个资源（常用）

HEAD: 仅请求响应首部

POST：提交表单（常用）

PUT: (webdav) 上传文件（但是浏览器不支持该方法）

DELETE：(webdav) 删除

OPTIONS：返回请求的资源所支持的方法的方法

TRACE: 追求一个资源请求中间所经过的代理（该方法不能由浏览器发出）

那什么是URL、URI、URN？

URI Uniform Resource Identifier 统一资源标识符

URL Uniform Resource Locator 统一资源定位符

格式如下： scheme://[username:password@]HOST:port/path/to/source

http://www.magedu.com/downloads/nginx-1.5.tar.gz

URN Uniform Resource Name 统一资源名称

URL和URN 都属于 URI

为了方便就把URL和URI暂时都通指一个东西

请求的协议有哪些种？

有以下几种：

http/0.9: stateless

http/1.0: MIME, keep-alive (保持连接), 缓存

http/1.1: 更多的请求方法，更精细的缓存控制，持久连接(persistent connection) 比较常用

下面是Chrome发起的http请求报文头部信息

其中

Accept 就是告诉服务器端，我接受那些MIME类型

Accept-Encoding 这个看起来是接受那些压缩方式的文件

Accept-Lanague 告诉服务器能够发送哪些语言

Connection 告诉服务器支持keep-alive特性

Cookie 每次请求时都会携带上Cookie以方便服务器端识别是否是同一个客户端

Host 用来标识请求服务器上的那个虚拟主机，比如Nginx里面可以定义很多个虚拟主机

那这里就是用来标识要访问那个虚拟主机。

User-Agent 用户代理，一般情况是浏览器，也有其他类型，如：wget curl 搜索引擎的蜘蛛等

条件请求首部：

If-Modified-Since 是浏览器向服务器端询问某个资源文件如果自从什么时间修改过，那么重新发给我，这样就保证服务器端资源

文件更新时，浏览器再次去请求，而不是使用缓存中的文件

安全请求首部：

Authorization: 客户端提供给服务器的认证信息；

什么是MIME？

MIME（Multipurpose Internet Mail Extesions 多用途互联网邮件扩展）是一个互联网标准，它扩展了电子邮件标准，使其能够支持非ASCII字符、二进制格式附件等多种格式的邮件消息，这个标准被定义在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。由RFC 822转变而来的RFC 2822，规定电子邮件标准并不允许在邮件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英语字符消息和二进制文件，图像，声音等非文字消息都不能在电子邮件中传输。MIME规定了用于表示各种各样的数据类型的符号化方法。此外，在万维网中使用的HTTP协议中也使用了MIME的框架，标准被扩展为互联网媒体类型。

MIME 遵循以下格式：major/minor 主类型/次类型例如：



1

5
|

image
/jpg

image
/gif

text
/html

video
/quicktime

appliation
/x-httpd-php

4.服务器端响应http请求，浏览器得到html代码

看下图第12号包是http请求包，第32包是http响应包

服务器端WEB程序接收到http请求以后，就开始处理该请求，处理之后就返回给浏览器html文件。

第32号包是服务器返回给客户端http响应包（200 ok 响应的MIME类型是text/html），代表这一次客户端发起的http请求已成功响应。200 代表是的响应成功的状态码，还有其他的状态码如下：

1xx: 信息性状态码

100, 101

2xx: 成功状态码

200：OK

3xx: 重定向状态码

301: 永久重定向, Location响应首部的值仍为当前URL，因此为隐藏重定向;

302: 临时重定向，显式重定向, Location响应首部的值为新的URL

304：Not Modified 未修改，比如本地缓存的资源文件和服务器上比较时，发现并没有修改，服务器返回一个304状态码，

告诉浏览器，你不用请求该资源，直接使用本地的资源即可。

4xx: 客户端错误状态码

404: Not Found 请求的URL资源并不存在

5xx: 服务器端错误状态码

500: Internal Server Error 服务器内部错误

502: Bad Gateway 前面代理服务器联系不到后端的服务器时出现

504：Gateway Timeout 这个是代理能联系到后端的服务器，但是后端的服务器在规定的时间内没有给代理服务器响应

用Chrome浏览器看到的响应头信息：

Connection 使用keep-alive特性

Content-Encoding 使用gzip方式对资源压缩

Content-type MIME类型为html类型，字符集是 UTF-8

Date 响应的日期

Server 使用的WEB服务器

Transfer-Encoding:chunked 分块传输编码是http中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分，分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供

Vary 这个可以参考（http://blog.csdn.net/tenfyguo/article/details/5939000）

X-Pingback 参考（http://blog.sina.com.cn/s/blog_bb80041c0101fmfz.html）

那到底服务器端接收到http请求后是怎么样生成html文件？

假设服务器端使用nginx+php(fastcgi)架构提供服务

① nginx读取配置文件

我们在浏览器的地址栏里面输入的是 http://www.linux178.com （http://可以不用输入，浏览器会自动帮我们添加），其实完整的应该是http://www.linux178.com./ 后面还有个点（这个点代表就是根域，一般情况下我们不用输入，也不显示）,后面的/也是不用添加，浏览器会自动帮我们添加（且看第3部那个图里面的URL），那么实际请求的URL是http://www.linux178.com/，那么好了Nginx在收到浏览器 GET / 请求时，会读取http请求里面的头部信息，根据Host来匹配自己的所有的虚拟主机的配置文件的server_name,看看有没有匹配的，有匹配那么就读取该虚拟主机的配置，发现如下配置：