HTTP协议探究(序章)

Wesley13
• 阅读 875

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就不可以)
点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
待兔 待兔
4个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
海军 海军
3年前
5分钟快速梳理你的HTTP体系
HTTP定义1.HTTP(超文本传输协议)是客户端与服务端之间信息交流的桥梁。2.在信息交流之前必须要做的就是客户端通过连接TCP/IP协议80端口,以便服务端侦听HTTP请求。3.HTTP是一种通用的,无状态的应用层协议,基于标准客户机/服务器模型。HTTP特点1.采用“请求/
xiguaapp xiguaapp
3年前
tcp的三次握手四次挥手
tcp的三次握手流程:在tcp/ip协议中,tcp协议提供可靠的连接服务,采用三次握手建立一个连接。第一次握手:建立连接时,客户端发送SYN包【synj】到服务器,并进入SYN_SEND状态,等待服务器确认;第二次握手:服务器收到SYN包,必须确认客户的SYN(ackj1),同时自己也发送一个SYN包(syn
Stella981 Stella981
3年前
Http基础解析
Http基础解析\\概念\\:HyperTextTransferProtocol超文本传输协议\传输协议:定义了,客户端和服务器端通信时,发送数据的格式\特点:1\.基于TCP/IP的高级协议2\.默认端口号:803\.基于请求/响应模型的:一次请求对应一次响应4\.
Wesley13 Wesley13
3年前
34.TCP取样器
阅读文本大概需要3分钟。1、TCP取样器的作用   TCP取样器作用就是通过TCP/IP协议来连接服务器,然后发送数据和接收数据。2、TCP取样器详解!(https://oscimg.oschina.net/oscnet/32a9b19ba1db00f321d22a0f33bcfb68a0d.png)TCPClien
Wesley13 Wesley13
3年前
HTTP协议简介
关于HTTP协议的基本介绍。<!moreHTTP协议是基于TCP/IP协议之上的应用层协议,主要用于规定互使用联网中客户端和服务器之间的通信格式,不关心具体传输细节,默认80端口。对于Web开发,不管是前端还是后端开发,了解HTTP协议是必备的一些基本知识。发展历程HTTP/0.9于
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
Mebius Mebius
1年前
什么是代理ip?代理ip的用途有哪些?该如何获取代理ip?
我们在网页中输入网址后发生了什么呢?1.浏览器获取域名2.通过DNS协议获取域名对应服务器的ip地址3.浏览器和对应的服务器通过三次握手建立TCP连接4.浏览器通过HTTP协议向服务器发送数据请求5.服务器将查询结果返回给浏览器6.四次挥手释放TCP连接7
Python进阶者 Python进阶者
10个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这