传输层重点协议：TCP协议、UDP协议

1. UDP协议

职责：在网络层的基础上，实现了进程to进程的通信

   

UDP协议的包头信息：UDP添加的封装（解包、分用）
    发送：1.填充端口
               2.计算长度+填充长度
               3.计算机checksum+填充checksum
               4.立即将数据交给网络层
    接受：1.从网络层接受数据
               2.通过计算校验和，检查数据是否出现错误了，如果错误直接丢弃
               3.数据没有错，根据自己内部的维护Map<port,pid> 找到对应的接收进程。如果找不到，直接丢弃
               4.看对应的进程是否准备好一块内存，如果暂时没有，需要暂时把数据保存一段时间
               5.把数据复制到对应的内存空间byte[] buf
    UDP的特点：

         不可靠：没有任何安全机制，发送端发送数据报以后，若因为故障无法发送，UDP协议不会给应用层返回任何信息；

        无连接：知道对端的IP和端口号就直接进行传输，不建立连接；

        面向数据报文：应用层交给UDP多长的报文，UDP原样发送，不拆分不合并；

        大小受限：16位最大长度，也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部）。

        UDP只有接收缓冲区没有发送缓冲区。

  基于 UDP 的应用层协议

        NFS：网络文件系统

        TFTP：简单文件传输协议

        DHCP：动态主机配置协议

        BOOTP：启动协议（用于无盘设备启动）

        DNS：域名解析协议

2. TCP协议 ：传输控制协议

    1.进程to进程         2.可靠（并不是安全！！）

2.1 TCP协议格式：

源/ 目的端口号：表示数据是从哪个进程来，到哪个进程去

32位序号/32 位确认号：32位序号是为传送的数据中的每一个字节按顺序编号；32位确认号只有在ACK被置位的时候才有效

4位TCP 报头长度：表示该 TCP 头部有多少个 32 位 bit （有多少个 4 字节）；所以 TCP 头部最大长度是 15 * 4 = 60

6位标志位:

        URG：紧急指针是否有效

        ACK：确认号是否有效

        PSH：提示接收端应用程序立刻从 TCP 缓冲区把数据读走

        RST：对方要求重新建立连接；我们把携带 RST 标识的称为 复位报文段

        SYN：请求建立连接；我们把携带 SYN 标识的称为 同步报文段

        FIN ：通知对方，本端要关闭了，我们称携带 FIN 标识的为 结束报文段

16 位窗口大小：存放了发送窗口的大小，16位数字表示65535，但是并不意味着TCP窗口就是65535字节，实际上TCP首部40字节选项中还包含一个窗口扩大因子M，实际窗口大小是窗口字段的zhi

16 位校验和：发送端填充， CRC 校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP 首部，也包含 TCP 数据部分

16 位紧急指针：标识哪部分数据是紧急数据

40 字节头部选项：暂时忽略

2.2 TCP的保证“可靠性”

        1.TCP会尽自己最大的努力，将数据发送给对方
        2.如果真的遇到发送不过去的情况，TCP至少会告诉发送进程，数据发送失败了
        3.保证不会收到错误的数据（通过checksum）
        4.TCP能保证收到的数据一定是有序的（按照发送进程发送时的顺序）
        5.TCP会根据对方的接受能力和网络线路的承载能力，进行流量控制

2.3 TCP做了哪些机制来保证可靠性

1.确认应答机制（安全机制）：接收方（对方的TCP）有责任对收到的数据进行确认应答
        ①确认段：一份数据既可以当发送的，也可以起到确认的角色
        ②发送：携带有数据，填写正确的SN，就是发送segment
        ③确认：标志位ACK置1，代表起到了确认的作用，需要填写确认序列号（ASN）
        ④确认序列号：填写下一次期望收到的第一个字节的编号，换言之，ASN之前的数据已经全部收到了
        ⑤TCP维护着各自的发送SN

2.TCP超时重传机制（安全机制）： 主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B；如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发； 但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了。TCP的发送端不用关心超时没有收到应答的原因是什么，采用统一的超时重传机制即可，如果接收端真的收到了重复的数据，TCP协议需要能够通过序列号识别出重复的包，直接丢弃即可。

超时重传不是无限制的：达到上限，发送方（TCP）认为本次数据线路出现重大问题了
    1.TCP关闭本次连接
    2.TCP会通知进程（IOException）
    3.TCP会发送一个reset segment出去

超时时间的设置：一般不是一个固定的长度，大多数是逐步变长

        1.最理想状态下，找到一个最小时间，保证“确认应答一定能在这个时间内返回”

        2.时间的长短随网络环境的不同有差异

        3.超时时间太长会影响整体的传重效率，时间太短有可能会频繁发送重复的包         

进程：作为TCP的发送方，经过一段时间之后，是可以知道线路有问题的
           作为TCP的接受方，无法得到线路有问题（不能确定对方是没有发送数据还是发送失败了）

连接管理机制（安全机制）：TCP需要三次握手建立连接，四次挥手断开连接

三次握手和四次挥手（面试必问） - My_Dreams - 博客园 (cnblogs.com)

1.TCP有没有发送缓冲区
   有、发送数据之后不可以直接丢弃，需要重发，所以至少需要一个地方保存这些数据
2.TCP有接收缓存区
3.TCP得维护发送时的序号SN= x，才可以用于发送时填充SN字段
   TCP得维护已经接收的数据的信号ASN=y，才可以进行去重

？为什么TCP要设计连接？
1.必须确认对方的存在，才能“可靠“地传输
2.交换一些必要的数据：SN不是直接从1开始的，会双方各自随机生成，随后需要交换

滑动窗口机制（效率机制）：一次发送多条数据提高性能                                                              

        1.窗口大小指的是无需等待确认应答可以直接发送数据的最大值 

        2.窗口大小为n个字节（n个段），表示发送前n个段时，不需要等待任何ACK后，直接发送

        3.收到第一个ACK以后滑动窗口向后移动，继续发送第n+1个段的数据，以此类推

        4.操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区来记录当前还有哪些数据没有应答

        5.只有确认应答过的数据，才能从缓冲区删掉

        6.窗口越大，则网络的吞吐率就越高

流量控制（安全机制）：接收端处理数据的速度有限，发送端发送太快接收端的缓冲区直接被打满，此时发送端继续发送就会丢包，因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，让发送端发送数据的速率不要太快让接收端来的及接受，这就是流量控制。

        1.接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端

        2.窗口大小字段越大，说明网络的吞吐量就越高

        3.接收端发现缓冲区快满了，就将窗口大小设置成一个更小的值通知给发送端

        4.发送端接收到这个窗口后就减慢自己的发送速度

        5.接受缓存区满了以后，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

拥塞控制（安全机制）：网络上有很多计算机很可能刚开始网络就已经比较拥堵，此时再发送大量数据更堵塞，拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不过载。因此TCP引入慢启动机制，先发少量数据摸清当前网络拥堵状态，再决定按照多大的速度传输数据。

        1.发送开始的时候，定义一个拥塞窗口大小为1

        2.每次收到一个ACK应答，拥塞窗口加1

        3.每次发送数据报的时候，将拥塞窗口和接收端主机反馈的窗口大小比较，取较小值作为实际发送的窗口

        “慢启动”只是指初始时慢，但实际窗口增长是指数级的

        4.当拥塞窗口超过慢启动的阈值时，不再按照指数方式增长，而是线性增长

       

        5.TCP开始启动的时候，慢启动阈值等于窗口最大值

        6.每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1

        

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；当TCP 通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降； 拥塞控制，归根结底是 TCP 协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

延迟应答（效率机制）：如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小

         假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；

        但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；

        在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；

        如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是

1M； 

窗口越大，网络吞吐量就越大，传输效率就越高，我们需要在保证网络不拥塞的情况下尽量提高传输效率；

并不是所有的包都可以延迟应答，每隔N个包就应答一次，或者超过最大延迟时间就应答一次（N一般取2，超过时间取200ms）；

捎带应答（效率机制）：客户端和服务器在应用层也是“一发一收”的，服务器在回复客户端发送的消息时，可以将ACK捎带上。

TCP 异常情况

进程终止：进程终止会释放文件描述符，仍然可以发送 FIN 。和正常关闭没有什么区别。

机器重启：和进程终止的情况相同。

机器掉电 / 网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset 。即使没有写入操作， TCP 自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放。

另外，应用层的某些协议，也有一些这样的检测机制。例如 HTTP 长连接中，也会定期检测对方的状态。 例如QQ ，在 QQ 断线之后，也会定期尝试重新连接。

TCP小结

TCP特点：面向字节流  有缓冲区  有大小限制   可靠性  性能高

TCP 要保证可靠性，同时又尽可能的提高性能所以比较复杂

可靠性：校验和 序列号（按序到达） 确认应答 超时重发 连接管理 流量控制 拥塞控制

提高性能： 滑动窗口 快速重传 延迟应答 捎带应答

TCP/UDP对比

TCP用于可靠传输的情况，应用于文件传输，重要状态更新等场景；

UDP用于对高速传输和实时性要求较高的通信领域，例如，早期的QQ，视频传输等。另外

UDP可以用于广播；

3. 相关问题

1. UDP 本身是无连接，不可靠，面向数据报的协议，如果要基于传输层 UDP 协议，来实现一个可靠传输，应该如何设计？

2. UDP 大小是受限的，如果要基于传输层 UDP 协议，传输超过 64K 的数据，应该如何设计？

        参考应用层的可靠性 机制：引入序列号，保证数据顺序； 引入确认应答，确保对端收到了数据；引入超时重传，如果隔一段时间没有应答，就重发数据……

3. TCP断开链接时客户端收到服务器发来的结束报文段进入TIME_WAIT，发出LAST_ACK，为什么TIME_WAIT的时间是2MSL？        

         MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失（否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的）；同时也是在理论上保证最后一个报文可靠到达（假设最后一个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK）；        

4. 服务器上出现大量的CLOSE_WAIT？

        服务器上出现大量的CLOSE_WAIT状态，原因就是服务器没有正确关闭socket，导致四次挥手没有正确完成，只需要加上对应的close即可解决问题。

5. 通过滑动窗口机制传输的时候，如果出现了丢包，如何进行重传？

        ①数据包已经抵达，但ACK被丢了：这种情况下，部分ACK丢了并不要紧，因为可以通过后续ACK进行确认；

        ②数据包直接就丢了：当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 "我想要的是1001" 一样；如果发送端主机连续三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 - 2000 重新发送；这个时候接收端收到了 1001后，再次返回的ACK就是7001了（因为2001 - 7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；这种机制被称为 "高速重发控制"（也叫 "快重传"）。

6. TCP协议如何避免粘包问题？（并无实际意义）

         对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小

的，那么就从缓冲区从头开始按sizeof（Request）依次读取即可；

        对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位

置；或者还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）