目录

1.应用层协议

2.传输层协议

3.UDP协议格式

4.TCP协议格式

5.TCP的安全效率机制

1.确认应答机制

2.超时重传机制

但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了；

3.连接管理机制

面试题：会不会有可能变成三次挥手？

面试题：第二个FIN丢包了如何处理？

4.滑动窗口机制

情况一：数据包已经抵达，ACK被丢了

情况二：数据包就直接丢了

滑动窗口效率：

那么滑动窗口取多大最合适呢？

5.流量控制

6.拥塞控制

---

1.应用层协议

确定数据组织格式，常用的协议有XML，JSON

2.传输层协议

3.UDP协议格式

 

4.TCP协议格式

• 源/目的端口号：表示数据是从哪个进程来，到哪个进程去；
• 4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是15 * 4 = 60
• 6位标志位:
• URG：紧急指针是否有效
• ACK：确认号是否有效
• PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
• RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段
• SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
• FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段
• 16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分。
• 16位紧急指针：标识哪部分数据是紧急数据；

5.TCP的安全效率机制

1.确认应答机制

解决了发收乱序的问题

2.超时重传机制

• 主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；
• 如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发；

但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了；

因此主机B会收到很多重复数据，那么TCP协议可以利用前面提到的序列号，就可以很容易做到去重的效果

• 最理想的情况下，找到一个最小的时间，保证 "确认应答一定能在这个时间内返回"。
• 但是这个时间的长短，随着网络环境的不同，是有差异的。
• 如果超时时间设的太长，会影响整体的重传效率；
• 如果超时时间设的太短，有可能会频繁发送重复的包；

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定
• 超时重发的超时时间都是500ms的整数倍。
• 如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传
• 如果仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增。
• 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

3.连接管理机制

在正常情况下，TCP要经过三次握手建立连接

 在这个基础上，双方就可以正常的接收发送

三次握手还有一个重要功能，就是协商序列号从哪里开始

面试题：三次挥手的过程

面试题：三次挥手过程能简化成两次吗？四次呢？

两次不可以，没有完整验证双方的收发能力

四次挥手断开连接

12表示客户端发送的断开请求，被服务器接受并应答，服务器会做一些断开前的准备

34表示应用程序的断开请求，比如调用了close（）方法

接收到客户端的应答CAK之后，服务器就可以释放资源

若出现大量close_wait则可能是应用程序没有正确关闭资源

面试题：会不会有可能变成三次挥手？

 ACK是操作系统实现的TCP协议的应答

第二个FIN是应用程序级别的，这两个操作之间是有时间差的，

大概率不会合并在一起

面试题：第二个FIN丢包了如何处理？

触发超时重传机制

4.滑动窗口机制

 

 

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）。
• 发送前四个段的时候，不需要等待任何ACK，直接发送；
• 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
• 操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应 答；只有确认应答过的数据，才能从缓冲区删掉；
• 窗口越大，则网络的吞吐率就越高；

 那么如果出现了丢包，如何进行重传？这里分两种情况讨论

情况一：数据包已经抵达，ACK被丢了