Linux网络--5、传输层协议
目录
一、前言
二、UDP
2.1协议格式
2.2特性
2.3数据报与缓冲区
2.4基于UDP的相关协议
三、TCP
3.1协议格式
3.2特性
3.3CS端保证特性
3.3.1可靠性
3.3.1.1序列号
3.3.1.2三次握手与四次挥手
3.3.1.3超时重发
3.3.1.4流量控制
3.3.2提高性能
3.3.2.1滑动窗口
3.3.2.1快速重传
3.4网络段保证特性
3.4.1可靠性
3.4.1.1拥塞控制
3.4.2提高性能
3.4.2.1捎带应答
3.4.2.2延迟应答
3.5TCP异常情况
3.6基于TCP的协议
一、前言
之前我们介绍了UDP和TCP的代码使用和部分特性，今天我们正式从理论学习传输层这两个关键的协议。
当我们在应用层完成对data的包装协议化，报文就进入到传输层进行传输，如何保证报文传输的稳定，安全，高效？
二、UDP
2.1协议格式
16位源端口号：发送主机的端口号
16位目的端口号：接受主机的端口号
16位UDP长度：包括8字节的报头属性和数据长度之和
16位校验和
2.2特性
（1）⽆连接: 知道对端的IP和端⼝号就直接进⾏传输, 不需要建⽴连接;（2）不可靠: 没有确认机制, 没有重传机制; 如果因为⽹络故障该段⽆法发到对⽅, UDP协议层也不会给应⽤层返回任何错误信息;（3）⾯向数据报: 不能够灵活的控制读写数据的次数和数量;
2.3数据报与缓冲区
应用层交给传输层的报文UDP不会拆分也不会合并，仅原样发送，最大发送位64kb
缓冲区：
（1）UDP无真正意义上的发送缓冲区，将数据直接sendto到内核进行后续操作
（2）UDP具有接收缓冲区，但不保证发送和接收的顺序一致
2.4基于UDP的相关协议
三、TCP
3.1协议格式
（1）相比于UDP协议的格式TCP多了序号和确认序号，标志位，窗口大小等字段，因为tcp具有面向字节流，有连接，安全等特性，所以设计也就复杂一点。
（2）tcp的大小计算与udp有所不同。tcp报头中的4位首部长度的单位为4字节，即4位首部长度的数值*4（0101->5，5 * 4 = 20），tcp报头标准为20字节，不算选项部分
（3）详细内容后面介绍
3.2特性
3.3CS端保证特性
为实现TCP的传输特性，客户端与服务端从以下几个方面来保证数据的正常传输
3.3.1可靠性
3.3.1.1序列号
（1）TCP对每个字节的数据都提供了相应的编号，即序号，可以看作是数组下标
（2）tcp发送消息是一批数据同时发送（均有对应序号），再同时进行应答，应答时会包含确认序号，告诉对方确认序号之前的数据已经确认收到。因此确认序号 = 序号 + 1
3.3.1.2三次握手与四次挥手
正常情况下双方由tcp建立连接要经过三次握手建立连接，四次挥手断开连接
1.为什么是三次握手四次挥手？
（1）因为tcp是全双工的，我们要保证两边都要建立连接，一次要确保c->s和s->c都可以进行连接传输，一次请求就有一次应答；
由于服务端对所有请求都要自动请求建立连接，所以在应答时可以捎带请求，简化四次为三次
断开连接时，c想断开s，但s有时不会断开c，所以有四次挥手，当想半断开时我们可以使用shutdown代替close
（2）验证全双工通信道的存在，保证网络通畅
2.所有ACK都是自动的
3.TIME_WAIT状态理解：
TCP协议规定,主动关闭连接的⼀⽅要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态MSL 是 TCP 报⽂的最⼤⽣存时间, 因此 TIME_WAIT 持续存在 2MSL 的话就能保证在两个传输⽅向上的尚未被接收或迟到的报⽂段都已经消失(否则服务器⽴刻重启, 可能会收到来⾃上⼀个进程的迟到的数据, 但是这种数据很可能是错误的);同时也是在理论上保证最后⼀个报⽂可靠到达(假设最后⼀个ACK丢失, 那么服务器会再重发⼀个 FIN. 这时虽然客⼾端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);
3.3.1.3超时重发
传输过程中可能会因为数据丢失或应答丢失造成没有完成传输，由于迟迟无法收到应答所以会在一个时间范围过后进行重传
TCP为了保证⽆论在任何环境下都能⽐较⾼性能的通信, 因此会动态计算这个最⼤超时时间.Linux中(BSD Unix和Windows也是如此), 超时以500ms为⼀个单位进⾏控制, 每次判定超时重发的超时时间都是500ms的整数倍.如果重发⼀次之后, 仍然得不到应答, 等待 2*500ms 后再进⾏重传.如果仍然得不到应答, 等待 4*500ms 进⾏重传. 依次类推, 以指数形式递增.累计到⼀定的重传次数, TCP认为⽹络或者对端主机出现异常, 强制关闭连接
3.3.1.4流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继⽽引起丢包重传等等⼀系列连锁反应.因此TCP⽀持根据接收端的处理能⼒, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);tcp报头中的窗口大小包含的是自己的缓冲区接收能力的剩余空间大小，传给对方进行传输控制（目前），其中16位数字最⼤表⽰65535, 那么TCP窗⼝最⼤就是65535字节么?实际上, TCP⾸部40字节选项中还包含了⼀个窗⼝扩⼤因⼦M, 实际窗⼝⼤⼩是 窗⼝字段的值左移 M 位;
3.3.2提高性能
3.3.2.1滑动窗口
起始序号是随机的，窗口由start和end两个下标组成，start = 确认序号，end = start + 窗口大小
（1）由于传输序号只能为增大趋势，所以窗口只能右滑
（2）窗口可大可小可为0
（3）不会出现越界，本质为环形
3.3.2.1快速重传
当某⼀段报⽂段丢失之后, 发送端会⼀直收到同样的确认序号的ACK，如果发送端主机连续三次收到了同样的应答, 就会将对应的数据重新发送;这种机制被称为 "⾼速重发控制"(也叫 "快重传").
3.4网络段保证特性
当cs两端保证传输后，网络在传输中也起很大作用所以我们要保证网络的传输
3.4.1可靠性
3.4.1.1拥塞控制
虽然TCP有了滑动窗⼝这个⼤杀器, 能够⾼效可靠的发送⼤量的数据. 但是如果在刚开始阶段就发送⼤量的数据, 仍然可能引发问题.因为⽹络上有很多的计算机, 可能当前的⽹络状态就已经⽐较拥堵. 在不清楚当前⽹络状态下, 贸然发送⼤量的数据, 是很有可能引起雪上加霜的.TCP引⼊ 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的⽹络拥堵状态, 再决定按照多⼤的速度传输数据;此处引⼊⼀个概念称为拥塞窗⼝发送开始的时候, 定义拥塞窗⼝⼤⼩为1;每次收到⼀个ACK应答, 拥塞窗⼝加1;每次发送数据包的时候, 将拥塞窗⼝和接收端主机反馈的窗⼝⼤⼩做⽐较, 取较⼩的值作为实际发送的窗⼝
像上⾯这样的拥塞窗⼝增⻓速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增⻓速度⾮常快.为了不增⻓的那么快, 因此不能使拥塞窗⼝单纯的加倍.此处引⼊⼀个叫做慢启动的阈值当拥塞窗⼝超过这个阈值的时候, 不再按照指数⽅式增⻓, ⽽是按照线性⽅式增⻓
3.4.2提高性能
3.4.2.1捎带应答
如三次握手我们可以在应答时传输数据
3.4.2.2延迟应答
如果接收数据的主机⽴刻返回ACK应答, 这时候返回的窗⼝可能⽐较⼩.假设接收端缓冲区为1M. ⼀次收到了500K的数据; 如果⽴刻应答, 返回的窗⼝就是500K;但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到⾃⼰的极限, 即使窗⼝再放⼤⼀些, 也能处理过来;如果接收端稍微等⼀会再应答, ⽐如等待200ms再应答, 那么这个时候返回的窗⼝⼤⼩就是1M;⼀定要记得, 窗⼝越⼤, ⽹络吞吐量就越⼤, 传输效率就越⾼. 我们的⽬标是在保证⽹络不拥塞的情况下尽量提⾼传输效率
3.5TCP异常情况
进程终⽌: 进程终⽌会释放⽂件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.机器重启: 和进程终⽌的情况相同. 机器掉电/⽹线断开: 接收端认为连接还在, ⼀旦接收端有写⼊操作, 接收端发现连接已经不在了, 就会进⾏reset. 即使没有写⼊操作, TCP⾃⼰也内置了⼀个保活定时器, 会定期询问对⽅是否还在. 如果对⽅不在, 也会把连接释放.另外, 应⽤层的某些协议, 也有⼀些这样的检测机制. 例如HTTP⻓连接中, 也会定期检测对⽅的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接
3.6基于TCP的协议
