了解传输层---UDP和TCP（满满的细节）

UDP协议

UDP协议端格式

注意： UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据 最大长度是64K(包含UDP首部).

UDP的特点

• 无连接：知道对端的IP和端口号就直接进行传输, 不需要建立连接;
• 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
• 面向数据报: 不能够灵活的控制读写数据的次数和数量;

总结：UDP只管传输，它就是一股脑儿将数据发送出去，并不会管你收没收到，读的时候也只能一份一份的读，就是要么将这份数据报内容读完，要么就不读，不会只读一半。

面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
例如：用UDP传输100个字节的数据:

• 如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;

UDP缓冲区

• UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核，由内核将数据传给网络层协议后进行hou’xu后续传输动作；
• UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;

基于UDP的应用层协议

• NFS: 网络文件系统
• TFTP: 简单文件传输协议
• DHCP: 动态主机配置协议
• BOOTP: 启动协议(用于无盘设备启动)
• DNS: 域名解析协议

TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;

TCP协议端格式

各字段的含义

(1) 源/目的端口号

因为TCP是传输层协议，它需要知道将数据发送给应用层的哪个进程，所以才会有端口号这一字段，源端口号表示数据从哪个进程来的，目的端口号表示数据要到哪个进程里去。

(2) 32位序号

TCP对每个字节的数据都进行了编号；
作用：用于保证数据的有序到达。（谁发送谁填）

(3) 32位确认序号

用于确认ACK有序；确认序号一般是序列号+1。
比如： 收到确认序号为10，则表明10号之前的数据全部收到，接下来发送的话就从10号开始。

(4) 4位TCP报头长度

表明该TCP头部有多少个4字节；比如该字段是0101 ，即代表该TCP头部的长度是 5 * 4=20 个字节；所以TCP头部最大长度是15 * 4=60个字节。

(5)六位标志位

• SYN：请求建立连接； 我们把携带SYN标识的称为同步报文段
• FIN：关闭连接； 我们称携带FIN标识的为结束报文段
• ACK：确认应答，表明是否有效；
• PSH：催促接收端应用程序赶紧将TCP缓冲区数据读走；
• RST: （连接重置）要求重新建立连接；我们把携带RST标识的称为复位报文段
• URG：紧急指针是否有效，下面将紧急指针；

(6)16位紧急指针

因为TCP能保证数据的有序性，所以数据是按序到达的，但是我们有时候需要将某些紧急数据优先到达，所以我们要打破这种按序到达的策略，这时候16位紧急指针就派上用场了，它指向的是本报文段中紧急数据的最后一个字节的序号，另外还存有偏移量。

(7)16位窗口大小

用来控制对方发送的数据量；告知对方自己的接收缓冲区中剩余空间的大小；

(8) 16位校验和

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

ACK机制

TCP将每个字节的数据都进行了编号. 即为序列号
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.

超时重传机制

那么，超时的时间如何确定呢？？

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

TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

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

连接管理机制

一般流程图如下：
应用层接口操作与TCP层操作对应关系，一目了然。

TCP为什么是三次握手，一次，两次，四次不行吗？？

答： 1. 用最小的成本验证全双工通信。
2. 让服务器不要出现连接建立的误判情况，减少服务器的资源浪费。

四次挥手的状态理解

• 要求主动断开连接的一方一定要进入TIME_WAIT状态，有什么意义？？
• 答： 1. 尽量保证最后一个ACK被对方收到，进而尽快释放资源。
• 2. 等待曾经的历史数据在网络上消散。

为什么是TIME_WAIT的时间是2MSL？？

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

小问题

为啥三次握手的时候，请求建立连接的包SYN和确认应答的包ACK（SYN+ACK）可以看作是一个包，而四次挥手时，请求断开连接的包FIN和确认应答的ACK包，不可以看作是一个包呢？？？

答： 因为断开连接的FIN是单向请求，必须应答。但是对方不一定想现在断开，所以FIN和ACK 不能合并。

滑动窗口

当我们每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段时，明显能感觉到这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.

所以就有了滑动窗口这一概念。

我们可以一次发送多条数据，让多个段的等待时间重叠在一起，这样就大大提高了性能。

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

注意滑动窗口的大小是动态变化的

它的大小=min(对方接受窗口大小，拥塞窗口大小)

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论.
情况一：数据包已经抵达, ACK被丢了.

当部分ACK丢失时，这种情况是不要紧的，因为可以通过后续的ACK再进行确认，如果收到确认序号为6001，表示之前的全部收到了。

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

要是接收方没有收到数据包，就会向发送方连续发送同样的确认序号，当发送方收到3个同样的确认应答时，就会重传，这种机制被称为”高速重发控制“（也叫快重传）

流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.

因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

这就要联想到我们上面讲的TCP首部了，在TCP首部有一个16位窗口大小的字段。在建立连接的时候，通信双方就会告知对方自己的窗口大小。

• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
• 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.
• 如果接收端又有了新的接收空间，就会向发送端发送一个窗口更新通知。

拥塞控制

当通信双方都没出现问题，但是就是收不到数据，这时候就要考虑是网络的问题了。

TCP会通过如果有大量的数据包丢失来判断是网络出现问题。

TCP引入慢启动来解决网络问题。

• 此处引入一个概念程为拥塞窗口
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口乘2;

但是这种增长速度是指数级别的，所以我们不能单纯的加倍，此处引入一个叫作慢启动阈值的概念。

• 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
• 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
• 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1；

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.

• 假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;
• 但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
• 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
• 如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

注意：窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

所以的包都可以延迟应答吗？？ 当然不是

• 数量限制: 每隔N个包就应答一次;
• 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

捎带应答

意思就是当服务器收到一个客户端发来的报文时，服务器想要回应这一报文，这时候就可以将ACK和应答一块发送给客户端。

面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;

-调用write时, 数据会先写入发送缓冲区中;

• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

• 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
• 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

粘包问题

• 首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.

产生原因：TCP无法辨别两个数据报之间的界限。
解决：

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
• 对于变长的包： http首部字段里面有一个Content-Length这一字段可以区分正文有多长，这样便可以区分。

TCP异常情况

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

机器重启: 和进程终止的情况相同.

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

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

理解全连接队列和半连接队列已经listen的第二个参数

1. 半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）。（即连接还未建立成功）
2. 全连接队列（accpetd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）。
3. 全连接队列的长度：listen的第二个参数+1.(原因：在linux内核中全连接队列判断是否已经满了的条件是==>==,解释一下就是如果你将listen的第二个参数设置为5，那么在底层只有连接个数大于5（即等于6）时才为真。)