1 HTTP协议基于TCP协议
(1)TCP三次握手连接
HTTP客户端(Chrome浏览器):
- IP:192.168.1.47
- 端口:59875
- MSS:1460
HTTP服务器(Nginx服务器):
- IP:45.76.37.162
- 端口:80
- MSS:1452
1 8.893857 192.168.1.47 45.76.37.162 TCP 66 59875 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2 9.151584 45.76.37.162 192.168.1.47 TCP 66 80 → 59875 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1452 SACK_PERM=1 WS=128 3 9.151807 192.168.1.47 45.76.37.162 TCP 54 59875 → 80 [ACK] Seq=1 Ack=1 Win=66560 Len=0
(2)第一个HTTP请求
4 9.152317 192.168.1.47 45.76.37.162 HTTP 461 GET / HTTP/1.1
# 具体报文
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
Host: 45.76.37.162\r\n
Connection: keep-alive\r\n
Cache-Control: max-age=0\r\n
Upgrade-Insecure-Requests: 1\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Language: zh-CN,zh;q=0.9\r\n
\r\n
(3)第一个HTTP响应(HTML)
# ACK报文告知客户端我已收到请求,你可以准备接收我的数据了。
5 9.409851 45.76.37.162 192.168.1.47 TCP 60 80 → 59875 [ACK] Seq=1 Ack=408 Win=30336 Len=0
6 9.410305 45.76.37.162 192.168.1.47 TCP 1506 80 → 59875 [ACK] Seq=1 Ack=408 Win=30336 Len=1452 [TCP segment of a reassembled PDU]
7 9.410551 45.76.37.162 192.168.1.47 TCP 1506 80 → 59875 [ACK] Seq=1453 Ack=408 Win=30336 Len=1452 [TCP segment of a reassembled PDU]
8 9.410552 45.76.37.162 192.168.1.47 HTTP 1089 HTTP/1.1 200 OK (text/html)
9 9.410580 192.168.1.47 45.76.37.162 TCP 54 59875 → 80 [ACK] Seq=408 Ack=3940 Win=66560 Len=0 # 客户端返回收到确认
# 服务器返回的最后一个报文的部分HTTP报文(省略实体内容)
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: nginx/1.12.2\r\n
Date: Wed, 21 Nov 2018 06:57:21 GMT\r\n
Content-Type: text/html\r\n
Content-Length: 3700\r\n # HTTP报文长为3700
Last-Modified: Tue, 06 Mar 2018 09:26:21 GMT\r\n
Connection: keep-alive\r\n
ETag: "5a9e5ebd-e74"\r\n
Accept-Ranges: bytes\r\n
\r\n
[HTTP response 1/2]
[Time since request: 0.258235000 seconds]
[Request in frame: 103]
[Next request in frame: 114] # 这里证明了一次TCP请求可以发送多次HTTP报文
[Next response in frame: 120]
File Data: 3700 bytes
- HTTP报文太长了,一个TCP段无法发送完,于是分成了n份,n为多少呢?
- HTTP报文长为3700,TCP MSS为1452,3700为HTTP实体大小 + HTTP首部(239)才是HTTP包的总大小 = 3939,3939 / 1452 = 3次。
- TCP客户端怎么知道TCP服务端,分段发送已经完成?
- 客户端HTTP请求时,发送PSH,ACK报文
- 服务器先返回ACK报文,告知收到
- 接着正式发送分段的HTTP报文(每次都是ACK)
- 最后一段HTTP报文为PSH,ACK报文
- 为什么HTTP请求时,发送的是PSH,ACK报文?
- 因为只放ACK报文,服务器无法确认客户端是否发送完毕了。
- 简而言之,PSH报文能够告知对方,我已发送完毕,请处理。
(4)第二个请求
10 9.419095 192.168.1.47 45.76.37.162 HTTP 404 GET /nginx-logo.png HTTP/1.1
# 具体报文
Hypertext Transfer Protocol
GET /nginx-logo.png HTTP/1.1\r\n
Host: 45.76.37.162\r\n
Connection: keep-alive\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36\r\n
Accept: image/webp,image/apng,image/*,*/*;q=0.8\r\n
Referer: http://45.76.37.162/\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Language: zh-CN,zh;q=0.9\r\n
\r\n
(5)第二个响应(图片)
11 9.679782 45.76.37.162 192.168.1.47 HTTP 660 HTTP/1.1 200 OK (PNG)
# 具体报文(省略实体报文)
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Server: nginx/1.12.2\r\n
Date: Wed, 21 Nov 2018 06:57:21 GMT\r\n
Content-Type: image/png\r\n
Content-Length: 368\r\n
Last-Modified: Tue, 06 Mar 2018 09:26:21 GMT\r\n
Connection: keep-alive\r\n
ETag: "5a9e5ebd-170"\r\n
Accept-Ranges: bytes\r\n
\r\n
[HTTP response 2/2]
[Time since request: 0.260687000 seconds]
File Data: 368 bytes
- Content-Length = 368,但是TCP payload 为606,606 < 1452,一次发送完毕。HTTP首部为238字节。
(6)省略TCP的4次挥手断开连接
2 总结
- HTTP协议基于TCP协议
- HTTP报文过长需要TCP分段传输
- 每次HTTP请求或响应都需要设置PSH标志为1,用于标志HTTP请求或响应完成
- TCP的MSS由双方共同决定,选择最小的值(如:1452 < 1460,所以为MSS),短板效应(防止处理速度快的一方压垮慢的一方)
- HTTP首部很长,上述两次首部一次为239字节,一次为238字节(HTTP2.0有改善,未来研究一下)。
- HTTP1.1协议可以在一次TCP连接中,发送多次HTTP报文(HTTP1.0就不可以)