文章目录
前言
传输层是整个网络体系结构中的关键层次之一，主要负责两个主机中进程之间的数据传输。在传输层中常见的协议就是TCP协议（传输控制协议）和UDP协议（用户数据报协议）。
一、UDP协议
1、UDP的协议格式
16位源端口：数据从哪一个端口发出来的，也就是数据从哪一个进程发送出来的。
16位目的端口：数据想要到哪一个端口去，也就是数据想要去往哪一个进程。
16位UDP长度：表示整个数据报(UDP头部+UDP数据)的最大长度。
16位的UDP校验和：校验数据在传输过程中是否失真，数据在传输的过程中需要经过很多链路设备，如果在转发过程中有某个字节损坏，就相当于整个这个数据失真了，如果UDP接收方校验和出错，就会直接将数据丢弃掉，且不会通知发送方。如果校验和出错, 就会直接丢弃
2、UDP的特点
特点为：无连接，不可靠，面向数据报。
无连接
即不需要建立连接也可以发送数据。只需要知道对端的端口号和ip地址就可以直接传输。就比如寄快递，只需要知道人家的地址就可以送过去，不需要与别人提前建立联系。
不可靠
即不能保证数据安全有序的到达对端。因为UDP不存在重传机制与确认机制，所以并不能保证数据能够到达对端，可能会在途中出现丢包，即使丢包了也不会报错和重传。UDP的报头中不存在序号，并且是无连接的，所以他没法保证数据到达后的顺序，需要我们自己在应用层进行包序管理。
面向数据报
即不能灵活的控制读写次数与数据的长度，是一种限制了传输数据大小的传输方式。并且UDP的数据传输是整条的，不会拆分和合并数据。
数据报长度字段只有16位，报头要占8个字节，所以数据报的长度不能大于65536。
UDP给应用层传下来的报文添加首部后就会直接转交给网络层，所以对于较大的数据，需要我们自己在应用层进行分包和包序管理进行多次发送。
UDP在报头中定义了数据长度，所以传输的时候都是整条收发。
所以接收时缓冲区必须要足够大，如果缓冲区大于或者小于一条数据的大小时都会接收失败，因为UDP不会交付半条或者多条数据。
比如用UDP传输100个字节的数据:
如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节
3.UDP的缓冲区
UDP的socket既能读, 也能写, 叫做全双工。
UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作。
发送缓冲区：将应用层数据打上UDP报头后直接递交给网络层。
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃。
接收缓冲区：去掉UDP报头后将数据递交给应用层。
UDP协议并不保证数据的有序到达。
4、基于UDP的应用层协议
NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议
5、UDP如何实现可靠传输
如果只依靠UDP本身是无法实现可靠传输的，因为其无法保证数据有序且到达，所以可以参考TCP的可靠性机制，在应用层也为其引入类似逻辑
- 引入序列号，保证数据有序
- 确认应答机制，保证对端能够收到数据
- 引入超时重传机制，保证数据不会丢失
二、TCP协议
（1）TCP的协议格式
源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去。
32位序号/32位确认号: 后面详细讲。
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60。
6位标志位：
URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
16位窗口大小: 指定滑动窗口的大小，即从TCP首部的确认序号所指位置开始能够接收的数据大小，TCP不允许发送超过此处所示大小的数据。用于实现滑动窗口机制，来进行流量控制
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分。
16位紧急指针: 标识哪部分数据是紧急数据(带外数据)，这段数据的优先级更高，会提前传送
40字节头部选项: 选项字段用于提高TCP的传输性能，主要协商和描述一些信息。因为TCP首部大小最高为60字节，而前面必须的有20字节，所以选项的大小可以为0-40字节
选项如图：
（2）确认应答机制
TCP在首部中给每一个发送的数据都设置了序号和确认序号。
通过序号和确认序号，发送方告诉了接收方我发送的数据的序号，以及数据的长度。而接收方则回复发送方，我已经收到了哪些数据，你下一次应该从哪一个位置开始发送。
seq:本条数据的起始序号。为上一条数据的ack。
ack:对对方发送数据的确认序号，告诉对方这个位置之前的所有数据已收到。确认序号为本条数据的起始序号加上数据长度。也就是上一条的seq + len。
len:本条数据的长度。
如下图：
但如果在传输过程中，前面的某一个数据丢失，即使这里的1025-2048和2049-3072已经到达，但是这些数据的依旧无法确认回复，因为确认回复必须要保证确认序号ack前的所有数据都要到达。这么做的目的是为了防止因为确认回复的丢失导致的重传。如下图：
即使是因为丢包或者延迟而导致前面的数据晚到或重传，等到接收到重传的数据后，再一个个对之前发送的数据进行确认应答，并通过序号在接受缓冲区中进行排序。
每一个ACK都带有对应的确认序列号:意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发。
TCP协议为什么要有序号：
确保TCP报文按序到达。
TCP协议为什么序号有两个，一个确认序号，一个序号：
因为TCP是全双工通信，双方同时通信双方的序号不一样，确认序号是通信对方确认应答。
（2）超时重传机制
主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B。
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发。还有可能主机A未收到B发来的确认应答, 也可能是因为ACK丢失了。如下图：
主机B会收到很多重复数据， 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果。
这个超时的时间也要合理：
最理想的情况下, 找到一个最小的时间, 保证 确认应答一定能在这个时间内返回。
但是这个时间的长短, 随着网络环境的不同, 是有差异的。
如果超时时间设的太长, 会影响整体的重传效率。
如果超时时间设的太短, 有可能会频繁发送重复的包。
然而TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间
Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时
时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传
如果仍然得不到应答, 等待4500ms 进行重传. 依次类推, 以指数形式递增
累计到一定的重传次数, TCP认为网络或者对端主机出现异常，强制关闭连接
（3）链接管理机制
TCP协议的连接是面向连接，可靠传输，面向字节流的，而TCP之所以能保持可靠传输是因为三次握手建立和四次挥手断开连接。
（一）、TCP三次握手
1、首先通过数据包名称和连接双方的连接状态来了解三次握手的过程：
客户端在发送SYN数据包后客户端的状态变为SYN_SENT，当服务端接收到客户端发送的SYN数据包后，服务端的状态变为SYN_RECV，当客户端接收到服务端的SYN数据包和ACK数据包后，客户端的状态变为ESTABLISHED，当服务端接收到客户端发送的ACK数据包时，服务端的状态变为ESTABLISHED，此时客户端和服务端已完成三次握手，即建立了双向连接
客户端状态转化:
[CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段。
[SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据。
服务状态转化:
[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接。开始监听（只有处于监听状态才会处理连接）
[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文。
2、感性理解：
第一次握手：客户端：在吗，我是C，你听到我说话了吗？
第二次握手：服务端：我听到你说话了，你听到我说话了吗？
第三次握手：客户端：我也听到你说话了，都能互相都能听到，那就开始通信吧。
3、问题补充
三次握手的作用：
第一次握手：client同步自己的发送序号seq和接收窗口win(还有其他的)，同时测试自己的发送能力是否正常
第二次握手：server发送确认号ack，证明了client发送正常，同时同步自己的发送信息seq和win，还要测试自己的发送能力是否正常
第三次握手：client发送确认号ack，证明server发送正常，发送信息同步完成 ，可靠性测试完成。
两次握手是否可以
前两次握手需要发送同步信息肯定是必不可少的，唯一有可能的是第三次，但是从上面分析来看，如果少了第三次握手，client知道自己的发送能力正常，发送信息也同步完成，但是server不能确定自己的发送能力是否正常，也不知道自己的发送信息是否同步完成，如果要建立连接，就必须确保双方都具有收发数据的能力并且当前处于在线状态，所以第三次握手不可少，。
而且如果是两次握手会造成两个后果：
1、如果客户端连续发送多次请求，服务端就会建立多次连接，严重的浪费资源。而SYN泛洪攻击就是客户端恶意不发送第三个握手包，OS在发送完第二次握手包后，会分配一些资源给这个半链接，同时将这个半链接放入半链接队列中，半链接过多时会导致server半链接队列满，正常的用户请求得不到响应，同时过多的半链接占用过多的资源影响server性能。
2、如果客户端发起SYN请求后就断开，或者是因为延迟很久才发到，等服务端收到时客户端已经断开连接，这时这个连接是失败的，但是服务端还是创建了一个毫无意义的套接字，严重浪费了资源。
四次握手是否可以
可能我们会想，第三次握手万一失了怎么办，是不是需要第四次握手来对第三次进行确认，首先第三次握手确实可能会丢失，假如第四次对第三次进行确认，那第四次需要第五次来确认，可以发现第四次还是更多次效果都是一样的，这样的协议不可能实现也没有任何效率，所以TCP采用了超时重传策略来保证传输的可靠，server在发送第二个之后，会开启一个定时器，超时后如果没有收到第三次的ack，它会重新发送SYN+ACK，如果失败三次后则说明链接失败。而且三次握手只是验证全双工通信，并不保证一定建立好链接。
完全没有必要，建立连接的SYN和确认回复的ACK报文是可以一起发送的，没有必要分开来增加操作
为什么TCP需要序号？
本质上是为了维护可靠传输，客户端维护了一套序号，服务端也维护了一套序号
client–>server：消耗(seq)的是客户端维护的序号，服务端告诉客户端自己收到数据的时候，是确认(ACK)客户端的序号
- server–>client：消耗(seq)的是服务端维护的序号，客户端告诉服务端自己收到数据的时候，是确认(ACK)服务端的序号。
TCP三次握手失败时，服务端如何处理？
1.如果服务端没有收到SYN，则什么都不做（因为压根没有建立起来连接，出现情况可能是SYN丢失）
2.服务端发送了SYN和ACK后，没有收到客户端的ACK，此时则说明客户端可能不在线，此时发送一个RST重置连接，并且释放已有资源。
（二）、TCP四次挥手
1、过数据包名和连接双方的状态分析四次挥手的过程如下图所示：
第一次挥手（客户端向服务端挥手）：客户端向服务端发送一个FIN请求断开连接，客户端处于FIN_WAIT_1状态。发送FIN表示发送端不再发送数据，但不代表不接收数据。
第二次挥手（服务端向客户端挥手）：服务端向客户端回复一个ACK确认收到了FIN。并且转为CLOSE_WAIT状态（此时服务端已经不再接受数据（关闭读操作），但是还会继续发送，所以此时会等待上层程序处理）
第三次挥手（服务端向客户端挥手）：此时服务端也完成了写操作，所以向服务端发送一个FIN请求断开连接，并且进入LASK_ACK状态。
第四次挥手（客户端向服务端挥手）：客户端收到了服务端的FIN，并且向服务端回复一个ACK表示已经收到。同时客户端进入TIME_WAIT状态。服务端收到ACK后断开连接进入CLOSED状态，客户端要等待2MSL也进入CLOSED状态。
原因：当主动断开方为TIME_WAIT状态时，如果主动断开方发送的ACK数据包丢失，则过MSL后，被动连接方会重新发送FIN数据包，让主动断开连接方重新发送ACK数据包，若主动断开连接方MSL后将状态变为CLOSED则无法收到重发的FIN数据包，无法重新发送ACK数据包。2MSL = 丢失的ACK的MSL + 重传的FIN的MSL。
2、感性理解
第一次挥手：C：我要说的话已经说完了。
第二次挥手：S：你要说的我都听到了，但是我的话还没说完。
第三次挥手：S：我要说的话也说完了。
第四次挥手：C：既然我们都说完了，那就结束通话。
3、问题补充
为什么断开需要四次挥手
1、TCP链接是全双工通信的，而断开时双方都需要确定两个问题，自己是否还有数据发送，而四次挥手双方在双方同步了这个两个问题
第一次挥手，c告诉s，自己的数据已全部发送，c可以回收发送缓冲区，s可以回收接收缓冲区
第二次挥手，s告诉c，自己收到了关闭信息
第三挥手，s告诉c，自己的数据已全部发送，s可以回收自己的发送缓冲区，c可以回收接收缓冲区
第四次挥手：c告诉s，自己收到了关闭信息
以上可以看出，四次挥手一样不能少，如果少了其中一个，那就造成总有一方不能可靠的通知对方自己的数据已发送完毕。因此，链接不可能可靠的断开，TCP也就成了不可靠协议。
2、发送FIN包只能代表着主动关闭方不再发送数据，但不代表着不再接收数据，所以被动关闭方在回复ACK后还是有可能继续发送数据，等到被动关闭方所有数据发送完后才会发送FIN，主动关闭方收到后回复ACK才会断开连接。这也就是为什么建立连接时ACK可以和SYN一起发送，而断开连接时FIN不能和ACK一起发送的原因。
TIME_WAIT的作用
在TIME_WAIT状态时，主动关闭方没有直接调用close释放资源，而是等到确保被动关闭方收到ACK确认后调用close，主动关闭方才调用。
如果没有TIME_WAIT,主动关闭方直接再发送完ACK后断开连接，就会有如下2种情况。
被动关闭方没有close释放资源，则新启用的客户端就有可能会出现和原来的客户端具有一样的地址信息。刚启用的新客户端绑定地址信息成功，但是此时却收到了被动关闭方重传的FIN,对新连接产生影响。
主动关闭方发送的ACK丢失，被动关闭方没有收到这个ACK，就会卡在LACK_ACK状态，所以超时后被动关闭方会重传一个FIN,如果新启用的客户端向服务端发送SYN连接，但是此时服务端处于LACK_ACK状态，此时他需要的是ACK而不是SYN，所以他会发送一个RST来重置连接。
所以为了避免上述几种情况，就添加了TIME_WAIT,等待一段时间确保被动关闭方收到ACK，即使没有收到，也留有了足够的时间来给被动关闭方进行FIN的重传。
一台主机上出现大量的TIME_WAIT是什么原因？如何处理？
TIME_WAIT状态是出现在主动关闭方的，如果出现大量的TIME_WAIT,就说明有大量的连接被主动关闭，可能是恶意攻击或者爬虫等。处理方法，调整TIME_WAIT的等待时间或者开启地址重用（运行新的套接字使用已绑定的地址端口，因为TIME_WAIT中的套接字无法绑定，启用后就可以直接顶替掉原来的）。
一台主机上出现大量的CLOSE_WAIT是什么原因？如何处理？
CLOSE_WAIT状态是在被动关闭方收到主动关闭方的FIN后进入的，此时主动关闭方已经不再发送数据，所以这时的被动关闭方的读端已经被关闭，但是被动关闭方还需要等到他所有的数据发送完才会结束，所以此时被动关闭方会等待上层应用进行处理，处理结束后才会发送FIN。而如果出现大量的CLOSE_WAIT，则说明被动关闭方的上层应用处理有问题，没有正确的关闭socket释放资源，所以此时就不会发送FIN，导致一直卡在CLOSE_WAIT。
（4）避免丢包重传机制
（1）滑动窗口
前言介绍
TCP在确认应答机制和超时重传机制下，已经可以保证数据是可靠有序到达对端，但是如果单单只有该两个机制，就会导致tcp的发送方在放松下一个数据之前，会等待上一个数据确认应答，这样整体的发送效率会比较低。
1、而滑动窗口机制允许发送方一次性发送多个分组到网络中进行传输，但发送方接收到最早分组的确认应答后，窗口可以向后移动，本质上是下标在更新，包括下一个可以发送的分组
2、滑动窗口机制提高了发送方和接收方的吞吐能力，提高了双方传输数据的效率。
一、理解滑动窗口
TCP以一个段为单位，每发一个段进行一次确认应答的处理。这样的传输方式有一个缺点是往返时间越长通信性能就越低。
对每一个发送的数据段, 都要给一个ACK确认应答.，收到ACK后再发送下一个数据段。这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长，如下图：
既然这样一发一收的方式性能较低, 那么我们一次并发 发送多条数据, 就可以很大提高性能(其实是将多个段的等待时间重叠在一起了）为解决这个问题，TCP引入了窗口这个概念。即使在往返时间较长的情况下，它也能控制网络性能的下降。如图所示，确认应答不再是以每个分段，而是以更大的单位进行确认时，转发时间将会被大幅度的缩短。也就是说，发送端主机，在发送了一个段以后不必要一直等待确认应答，而是继续发送。
窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。图中，窗口大小为4个段，也就是4000个字节。
发送前四个段的时候, 不需要等待任何ACK, 直接发送。
收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推。
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉。
窗口越大, 则网络的吞吐率就越高。
在收到确认应答下的情况，将窗口滑动到确认应答中的序列号的位置，这样可以顺序地将多个段同时发送，提高通信性能，这样的机制叫滑动窗口机制。如图：
滑动窗口补充问题
1 滑动窗口大小
在tcp双发送数据的时候，tcp发送方维护的窗口大小是允许一次性丢到网络当中分组的集合，分组的个数，发送方的窗口大小是动态变化的，取决于接收方通告的窗口大小。
tcp接收缓冲区窗口小并不是限制大，当应用层步调用recv从接收缓冲区当中获取数据的时候，就会导致tcp接收缓冲区随着一直接收发送方发送的数据导致接收缓冲区大小一直变小。
结论：
接收方通过窗口大小，告知发送方自己的接收能力，发送方在发送数据的时候会按照接收方通告自己的接收能力，动态调整自己的发送数据量。
2 数据包已经传输给对方，但是对方返回的ACK数据包丢失
首先，我们先考虑确认应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的。然而，在没有使用窗口控制的时候，没有收到确认应答的数据都会被重发。而使用了窗口控制，某些确认应答即便丢失也无需重发，因为部分ACK丢了并不要紧, 可以通过后续的ACK进行确认。
3、传输的数据包直接丢失，或者说是某个报文段丢失的情况
接收端在没有收到自己所期望序号的数据时，会对之前收到的数据进行确认应答。发送端则一旦收到某个确认应答后，又连续3次收到同样的确认应答，则认为数据段已经丢失，需要进行重发。这种机制比起超时机制可以提供更为快速的重发服务。
比如当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001开始的数据"一样。
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送。这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中。
快重传:当发送方发送的网络数据丢包之后，发送方还没有触发超时重传机制的时候，有接收方快速的确认丢失报文的起始序号， 告知发送方该报文丢失， 则发送方不需要等到超时之后才重传，这种机制被称为 “高速重发控制”。
（2）流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制。
如果接收端将本应该接收的数据丢弃的话，就又会触发重发机制，从而导致网络流量的无端浪费
它的具体操作：接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。在前面所介绍的窗口大小的值就是由接收端主机决定的。
TCP首部中，专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端。这个字段的值越大，说明网络的吞吐量越高。不过，接收端的这个缓冲区一旦面临数据溢出时，窗口大小的值也会随之被设置为一个更小的值通知给发送端，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制。这也就形成了一个完整的TCP流控制。
a.接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端。
b.窗口大小字段越大, 说明网络的吞吐量越高。
c.接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端。
什么时候回复发送方给接收方发送数据
1.发送方主动给接收方发送窗口探测包
询问接收方的接收能力，窗口探测包的数据的大小为固定的1字节
2.接收方主动给发送方发送窗口更新通知
e.发送端接受到这个窗口之后, 就会减慢自己的发送速度
f.如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 让接收端把窗口大小告诉发送端。
接收端如何把窗口大小告诉发送端?在TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息; 但是16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位。
一开始就要按照滑动窗口的大小， 发送数据吗?
不是， 还要考虑到网络的转发能力是否能够满足一次性传输窗口大小的数据。
（3）拥塞控制
背景：
有了TCP的窗口控制，收发主机之间即使不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。然而，如果在通信刚开始时就发送大量数据，也可能会引发其他问题。
一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。在网络出现拥堵时，如果突然发送一个较大量的数据，极有可能会导致整个网络的瘫痪。
TCP为了防止该问题的出现，在通信一开始时就会通过一个叫做慢启动的算法得出的数值，对发送数据量进行控制。
理解拥塞控制
虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜。
所以TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。
具体流程：
此处引入一个概念为拥塞窗口，发送开始的时候, 定义拥塞窗口大小为1个数据段（1MSS）。
每次收到一个ACK应答, 拥塞窗口加1。
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的滑动窗口大小做比较, 取较小的值作为实际发送的窗口。
结论
1.网络传输的时候，数据是在“共享网络”当中进行传输的。换句话说，网络被多个网络收发双发所使用。同时在转发多个人数据。
2.网络链路当中的路由器/交换机，转发能力有上限的。
3.网络链路当中的传输介质(光纤/双绞线)是由传输上限的。
TCP双方在发送数据的时候， 为了不是因为网络频繁的重传，则TCP双发在发送数据的时候， 也是考量网络转发能力的。
拥塞控制机制:本质也是在控制发送方发送数据的量
最终发送的数据量=min(发送方的滑动窗口大小(决于接收方的接收能力)
，拥塞控制机制当中的拥塞窗口大小(取决于网络拥塞程度))
观察
像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初始慢, 但增长速度非常快。为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍。
此处引入一个叫做慢启动的阈值。
当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长。
当TCP开始启动的时候, 慢启动阈值等于窗口最大值。
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。如图：
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞，当TCP通信开始后, 网络吞吐量会逐渐上升，随着网络发生拥堵, 吞吐量会立刻下降。
总结
1.早期 TCP发现网络拥塞之后，是将拥塞窗口调整为1(既一个分组)，从慢开始重新增长拥塞窗口大小 。发生网络拥塞重新调整慢开始门限。
慢开始门限(新)=拥塞发生时，拥塞窗口大小/2
2.现在TCP的做法;快恢复
一旦发送网路拥塞， 则计算新的慢开始门限， 从新的慢开始门限执行拥塞避免算法，拥塞窗口的大小一旦到达网络拥塞的情况时，拥塞窗口的大小会直接一下子变为慢启动时的阈值，即1个MSS，但是这种情况其实是不科学的，因为一次丢包有可能是正常的，这种正常的情况的发生有可能是网络闪断了，当网络闪断的时候，拥塞串口的大小就会被置为1，然后再慢启动，再进行拥塞控制，针对这种情况，我们就需要一种快恢复的机制。
TCP为了实现拥塞控制，总共采用了慢启动机制、拥塞避免机制、快重传机制和快恢复机制。
（5）拯救传输性能机制
（1）延迟应答
延时应答机制概念
接收方接收到了数据，为了给消息发送方通告更大的窗口大小， 等待一段时间， 如果在这段时间内， 应用层将数据从(recv函数)接收换缓冲区当中接收走之后，接收方在恢复确认时候，就可以给发送方通告更大的窗口大小了
接收数据的主机如果每次都立刻回复确认应答的话，可能会返回一个较小的窗口。那是因为刚接收完数据，缓冲区已满。当某个接收端收到这个小窗口的通知以后，会以它为上限发送数据，从而又降低了网络的利用率（这其实是窗口控制特有的问题，专门术语叫做糊涂窗口综合征）。为此，引入了一个方法，那就是收到数据以后并不立即返回确认应答，而是延迟一段时间的机制。
举例
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了，变回1M了。
所以在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来。如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M。
所有包都要应答？
并不是，窗口越大, 网络吞吐量就越大, 传输效率就越高.，我们的目标是在保证网络不拥塞的情况下尽量提高传输效率
数量限制: 每隔N个包就应答一次。
时间限制: 超过最大延迟时间就应答一次。
（2）捎带应答
捎带应答概念：
运用于双发都想给对方发送数据的场景，快速的进行交互，就将ack放到PSH数据包当中稍带给对方。
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “hello”, 服务器也会给客户端回一个 “hello”; 那么这个时候ACK就可以搭顺风车, 和服务器回应的 “hello” 一起回给客户端。
接收数据以后如果立刻返回确认应答，就无法实现捎带应答。而是将所接收的数据传给应用处理生成返回数据以后进再进行发送请求为止，必须一直等待确认应答的发送。也就是说，如果没有启用延迟确认应答就无法实现捎带应答。延迟确认应答是能够提高网络利用率从而降低计算机处理负荷的一种较优的处理机制。
（3）快速重传
前面已说过
（6）保活机制
心跳机制:判断空闲连接的双方是否是正常状态
在连接空闲的时候，就会启动一保活计时器，记录连接空闲的时间，一日当连接的空闲时间超过2小时，则服务端的TCP协议会主动给客户端发送保活探测包(心跳包)
如果10次探测包都没有应答，则认为对端已经处于不正常的状态， 则主动断开（如果服务端一直没有收到探测包的连接，则会每个75s发送一次，一共发十次）
如果有应答， 则认为连接正常，重新启动保活计时器进行计时
三、TCP面向字节流
TCP面向字节流：
从发送数据的角度理解:应用层的应用程序在发送数据的时候，是调用send函数将应用层数据递交给传输层的tcp协议，递交给tcp协议之后，数据是暂时保存在发送缓冲区当中。但不要认为，TCP在发送数据的时候，是按照应用程序调用send函数的规律来来进行发送的。
TCP发送数据一定是小于MSS， 有自己发送数据的规律。
从接收的角度来理解:当数据到达接收方的接收缓冲区之后，接收方的应用程序调用recv函数可以接收任意字节
创建一个TCP的socket, 即在内核中创建一个发送缓冲区和一个接收缓冲区：
调用write时, 数据会先写入发送缓冲区中。
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出。
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去。
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区。
然后应用程序可以调用read从接收缓冲区拿数据。
简单来说, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这叫做全双工。
缓冲区的存在, 可以让TCP的读和写不需要一一进行匹配
比如：
写200个字节数据时, 可以调用一次write写200个字节, 也可以调用200次write, 每次写一个字节。
读200个字节数据时, 也完全不需要考虑读的时候是怎么读的, 既可以一次read 200个字节, 也可以一次read一个字节, 重复200次。
四、TCP粘包问题
面向字节流服务会导致数据之间没有明显的边界，会导致TCP粘包问题，如果解决粘包问题，就需要在应用层自制协议 应用层头部+应用层数据+间隔符(\r\n)
TCP粘包
因为TCP协议是面向字节流的，上一次和下一次的数据没有明显的数据边界，即TCP通过recv函数接收数据的时候不会区分此条数据是第一次发送的还是第二次发送的，而是直接按规定的大小进行读取，因此有可能读取到不完整的数据或粘在一起的数据。
1.首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包。
2.在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段。
3.站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中。
4.站在应用层的角度, 看到的只是一串连续的字节数据。
5.那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包。
如上图所示客户端向服务端发送的是6+7和7+8，但服务端在接收数据的时候无法区分第一条和第二条数据，所以将第一条和第二条数据粘在一起接收，即接收到6+77+8，这种情况就是数据粘包问题。
TCP粘包问题解决
其实就是要明确两个包之间的边界
1.使用定长的字节发送：它的本质是设置固定的数据收发的字节大小，现实中我们发送数据有长有短，根据每条数据发送的长短给每条数据设置不同的收发长度显然不现实，所以此方法只适用于理论基础实现。
2.在应用层当中，对应用程序产生的数据进行“包装”，即给应用数据加上头部描述信息，在应用数据的尾部加上分隔符。
应用数据 = “zxcvbnm”
应用数据 = 应用层描述符数据的头部+“zxcvbnm”+分隔符
对于UDP协议来说 存在 “粘包问题” ？
1.对于UDP, 如果还没有向上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层，就有很明确的数据边界”。
2.站在应用层角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况。