HTTP1.1 wireshark分析

news2024/11/18 11:34:13

本地springboot启动一个简单的服务，然后请求测试

tcpdump -i lo0 -nnvv -w tmp.cap tcpdump 本地回环网卡

http1.1

HTTP/1.0 每进行一次通信，都需要经历建立连接、传输数据和断开连接三个阶段。当一个页面引用了较多的外部文件时，这个建立连接和断开连接的过程就会增加大量网络开销。

为了解决 HTTP/1.0 的问题，1999 年推出的 HTTP/1.1 有以下特点：

长连接：引入了 TCP 连接复用，即一个 TCP 默认不关闭，可以被多个请求复用
并发连接：对一个域名的请求允许分配多个长连接（缓解了长连接中的「队头阻塞」问题）
引入管道机制（pipelining），一个 TCP 连接，可以同时发送多个请求。（响应的顺序必须和请求的顺序一致，因此不常用）
增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法
新增了一些缓存的字段（If-Modified-Since, If-None-Match）
请求头中引入了 range 字段，支持断点续传
允许响应数据分块（chunked），利于传输大文件
强制要求 Host 头，让互联网主机托管称为可能
————————————————
版权声明：本文为CSDN博主「前端南玖」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41960279/article/details/123786121

wireshark分析http 1.1 keep-alive的2次http请求

当8080端口还没有好的时候，我们浏览器请求可以看到如下对话
在这里插入图片描述

客户端SYN要去链接，但是服务端一直返回RST。

附RST标志位:

RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。

TCP处理程序会在自己认为的异常时刻发送RST包。例如，A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。

又比如，AB正常建立连接了，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，网断了，A通过若干原因放弃了这个连接（例如进程重启）。网通了后，B又开始发数据包，A收到后表示压力很大，不知道这野连接哪来的，就发了个RST包强制把连接关了，B收到后会出现connect reset by peer错误。

SpringBoot项目8080端口启动成功后，可以看到TCP三次握手成功

在这里插入图片描述

接着看到Tcp window update：TCPWindowUpdate是TCP通信中的一个状态，可以发生的原因有很多，但最终归结于发送者传输数据的速度比接收者读取的数据还快，这使得接受端的在缓冲区必须释放一部分空间来装发送过来的数据，然后向发送者发送WindowsUpdate，告诉给发送者应该以多大的速度发送数据，从而使得数据传输与接受恢复正常。

附：Wireshark的TCP提示
Tcp previous segment lost（tcp先前的分片丢失）
Tcpacked lost segment（tcp应答丢失）
Tcp window update（tcp窗口更新）
Tcp dup ack（tcp重复应答）
Tcp keep alive（tcp保持活动）
Tcp retransmission（tcp重传）
Tcp ACKed unseen segument （tcp看不见确认应答）
tcp port numbers reused（tcp端口重复使用）
tcp retransmission（tcp重传）
tcp fast retransmission (tcp快速重传)
TCP Previoussegment lost（发送方数据段丢失）
tcp spurious retransmission(tcp伪重传)

接着http请求发送
在这里插入图片描述