文章插图
- 连接状态查看
netstat -tpn # t:TCP连接装，p:进程显示，n:数字形式# 每秒查看一次netstat -tpn -c 1
文章插图
TCP四次挥手
文章插图
- A: 发送FIN数据包，代表A不再发送数据
- B: 收到请求，开始应答，避免了A重新发送FIN重试(应答机制)
- B: 处理完数据之后关闭，关闭连接,及发送FIN请求
- A: 收到请求后发送ACK应答，B服务可以释放连接
等待 2MSL后释放连接
- 防止报文丢失，导致B重复发送FIN
- 防止滞留在网络中的报文，对新建立的连接造成数据扰乱
字节流的协议
TCP把应用交付的数据仅仅看成是一连串的无结构的字节流，TCP并不 知道字节流的含义，TCP并不关心应用程序一次将多大的报文发送到 TCP的缓存中，而是根据对方给出的窗口值和当前网络拥堵的程度来决 定一个报文段应该包含多少个字节 。
MSS: Max Segment Size, 默认 536byte 实际数据
文章插图
在网络传输过程中可能会出现以下的一些情况：
- 客户端一段时间没有收到 ack 消息则重传
- 如果缓冲区满了则可能丢包或延时都需要重传
- 根据报文 sequeence number 字段重排序，还需要丢弃重复包 。
数据传输的可靠性
停止等待协议如下：
文章插图
停止等待协议，效率比较低
重传机制如下：
- ack 报文丢失
文章插图
- 请求报文丢失
文章插图
滑动窗口协议与累计确认(延时ack)
如上效率低，所以tcp提出了新的协议-滑动窗口协议与累计确认（延时ack） 。
滑动窗口大小同通过tcp三次握手和对端协商，且受网络状况影响 。
上面是一个一个报文，实际可发一批报文，服务器并不是挨个去确认，上面回一个ack浪费资源，单独响应一个报文时，tcp本身一个报文至少20个字节再加上ip头报文20字节，所以一个ack至少40字节 。
所以延时ack的发送，如下图确认最后一个报文如5就可以，但这样也有一个问题如3的报文丢了，这时只能确认1和2连续报文，从3以后的报文全要重传，已确认的报文在缓冲区丢弃掉 。
文章插图
文章持续更新，可以公众号搜一搜「 一角钱技术 」第一时间阅读，本文 GitHub org_hejianhui/JAVAStudy 已经收录，欢迎 Star 。
推荐阅读
- 使用charles嗅探https请求，你的API并不安全
- 您一定得见识一下.Net中这几款HTTP请求库
- Wireshark数据包分析实战：HTTPS加解密过程
- 数据中台建设从数据中台的认知开始
- 找出两个链表的第一个公共节点
- 熊胆汁的作用
- 纯种哈士奇长啥样 纯种哈士奇多少钱一只,从这6点来看价格
- 剑网三一个赛季持续多久 剑网三赛季多久一次
- 怎样可以锻炼肌肉呢？
- 养猫和仓鼠 猫为什么喜欢仓鼠