TCP与UDP详解

1、TCP（传输控制协议）

1.1端口

• 传输层:为相互通信的应用程序提供逻辑通信，负责将数据从一端发送至另外一端
• 在UDP/IP协议中，用源IP地址 + 源端口号 + 目的IP地址 + 目的端口号 + 协议号（组成的套接字），这样的五元组来标识一个通信
• 端口号是一个32位的整数
• 端口号用来标识一个进程, 告诉操作系统, 当前的这个数据要交给哪一个进程来处理
• 端口范围的划分：
  1、0 - 1023: 知名端口号
  2、1024 - 65535: 操作系统动态分配的端口号
• 常见知名端口号
  

1.2 报文结构

源/目端口号：应用进程与应用进程之间通信的监听出入口。
序列号：序列号随机生成，每次序号都会不一样，有一个复杂的初始化算法。序列号会随着双方通讯而不断的增加。序列号一共32比特，最大值2^32-1，到达最大值后重新从0开始。
确认序列号：确认序列号是上次已成功接收到数据字节序列号加1。
首部长度：选项不用，TCP的头部为20字节；存在选项则为60字节。
保留：为将来定义新的用途保留，现在一般置0。
标志：每个标志占1比特，1表示有效，0为无效。

1. URG：紧急指针是否有效。有效会告诉系统此时有紧急数据需要尽快传送。
2. ACK：确认序号是否有效。仅当ACK=1时确认字段才有效。建立连接后，所有的传送的报文都必须把ACK置为1。
3. PSH：接收方应该尽快将这个报文段交给应用层。不必等待缓存区满后再向上交付
4. RST：复位，对方要求重新建立连接。当RST=1代表TCP连接出现严重差错，必须释放连接再重新建立连接。
5. SYN：同步序列号，请求建立连接。在连接请求中，SYN=1 ACK=0表示该数据段是未捎带确认的连接请求报文；SYN=1 ACK=1表示是一个捎带了确认的连接请求报文。
6. FIN：用于释放连接，FIN=1时表示发送方已经没有数据发送了，即关闭本方数据流。

窗口：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小最大为65535。
检验和：覆盖了整个TCP报文段：TCP首部和TCP数据，因为TCP是一个可靠的协议，所以这是强制性的字段，由发送方计算和设置，并由接收方进行验证，这就是可靠性保证的重要手段。
紧急指针：只有当URG=1才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个报文段。TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。
选项：就是TCP头部的不是“必须”的选项
数据：可选，在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

1.3 TCP的建立和终止

1.3.1 建立

描述：

1. 客户端发送一个SYN报文表示希望和服务器建立连接，并附带上一个客户端随机产生的序列号X。,此时进入SYN-SEND状态。（同步发送）
2. 服务端收到SYN请求后会发送给客户端SYN报文段作为应答。同时发送ACK报文段进行确认。并附带一个服务端随机产生的序列号Y和一个确认序列号X+1，此时为SYN-RCVD（同步收到）状态
3. 客户端收到服务端发送的响应包后，客户端发送确认包给服务端表示收到了服务端发送的SYN报文。确认包中包含序列号X+1和确认序列号Y+1，此时双方进入了ESTAB-LISHED(建立连接)状态。

当以上三个报文段完成交互后就证明连接已经建立，这个过程也成为“三次握手”。接下来客户端就可以发送数据给服务端，服务端可以响应数据。

经典面试题：为何TCP客户端最后还要发送一次确认呢？
主要防止已经失效的数据报文突然又传送到服务器，从而产生错误

1.3.2 终止

描述：

1. 客户端发送FIN报文希望主动关闭连接，报文中携带随机序列号U。此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务端收到这个FIN报文段时，它将发送给客户端一个ACK表示确认断开，此报文中携带随机序列号V和一个确认序列号U+1。此时，服务端就进入了CLOSE_WAIT（关闭等待）状态。
3. 服务端把收到的FIN的消息告诉应用程序，应用程序就会关闭它的连接。导致服务端发送一个FIN给客户端。报文中携带确认序列号U+1。由于半连接状态，服务端很可能又发送了一些数据。 此时，服务器就进LAST-ACK（最后确认）状态，等待客户端的确认。
4. 客户端收到服务端的FIN报文段时，此时，客户端就进入FIN-WAIT-2（终止等待2）状态。客户端会立刻对此FIN报文进行ACK回复，报文中包含序列号U+1和确认序列号V+1。此时TCP连接还没有释放，必须经过2MSL（最长长报文段生存）的时间后，才进入CLOSED状态。

注：TCP是全双工模式的，客户端关闭连接不代表服务端就可以立刻关闭，如果客户端发起关闭的时候，服务端还没有响应完数据给客户端，服务端还是需要把数据发完了再去关闭的，而客户端主动发起了闭关但不会立即关闭，而是进入“FIN_WAIT2”状态进行数据接收，此为半关闭。直到服务端发送完了并最后发送结束连接报文段FIN才进入TIME_WAIT状态。

1.3.3 为何需要三次握手，四次断开？

• 建立一个连接需要三次握手，而终止一个连接需要经过4次握手，这是由于TCP的半关闭造成的。既然一个TCP连接是全双工的（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。发送FIN通常是应用层关闭的结果，一般为客户端关闭连接。

1.3.4 MSL与2MSL等待时间

• TCP报文的在网络上单向传送的最大生存时间叫做MSL

• 2MSL（最大报文段生存时间）等待状态。之所以要等待，是因为关闭方要确认处于“CLOSE_WAIT”状态的被关闭方收到它最后的ACK报文，，等待确认报文来回的时间就是2MSL，如果被关闭方在2MSL内都没有收到ACK，就会重复发送FIN报文。如果关闭方在2MSL时间内未收到被关闭方的报文，则默认收到
  Windows : MSL = 2 min
  linux(Ubuntu, CentOs) : MSL = 60s

• 2MLS等待原因
  1、2MSL的时间能保证在两个传输方向上的未被接收的数据和迟到的数据全部被丢弃（当连接关闭时，有可能收到迟到的报文段。这时，若立马就建立新的连接（同一端口），那么新的连接就会接收迟到的报文，误以为是发给自己的）
  2、保证了最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了,但是TCP连接还在,仍然可以重发LAST_ACK）如果直到2MSL，客户端都没有再次收到FIN，那么客户端推断ACK已经被成功接收，则结束TCP连接。

注：报文在网络中的生存时间并不只由TCP决定的，网络层的IP协议对数据报同样存在着网络单向传送的时间限制，这个限制叫TTL。

1.3.5 同时打开和关闭

TCP建立连接不一定必须是三次握手，有时可能会是4次。

• 比如当双发同时进行请求主动打开连接的时候就是4次。此时并没有客户端和服务端之称，双方都有主动发送数据的权利。

1.4 可靠传输机制

确认应答机制和重传机制

• 当数据完整发送到对端时，对端会发送确认序列号（ACK）确保数据完整性，当数据中的某些数据段因为一些原因未能传输到对端时（丢包），就会采用重传机制对丢失的数据段进行重发。从而保证了数据的可靠性

如何确定超时重传时间？

• 系统基于TCP协议实现，动态计算报文最大生存时间（MSL）,超时时间设置为2MSL。
• 超过超时时间表示丢包，需要重新发数据。数据不会被反复，无限重发，达到一定次数强制关闭连接。

1.5 滑动窗口

• 滑动窗口
  用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小。窗口指一次批量发送多少数据

• 滑动窗口产生的原因
  在确认应答的策略中，每发送一次数据段都需要一个ACK确认应答，收到ACK后再发送下一个数据段，这样每次都需要确认，性能较差。采用滑动窗口的机制就会一次发送多条数据，提高传输性能

• 丢包后如何重传
  1、数据包并未丢失，ACK确认包丢失
  当窗口值较大时，即使有少量的确认应答丢失，也不会进行重传，可以通过下一个确认应答进行确认
  2、数据包直接丢失
  接收端在没有收到自己所期望序号的数据时，会对之前收到的数据进行确认应答。发送端一但收到某个确认应答后，又连续3次收到同样的确认应答，则认为数据段已经丢失，需要进行重发。这种机制比起超时机制可以提供更为快速的重发服务，也叫快重传。

1.6 流量控制

• 接收端通过TCP协议头中”窗口大小“字段，告知发送端发送数据的大小。
• 流量控制的目的：防止接收缓冲区被占满，再次接收到的数据就会被直接丢弃，接收端主机无法处理。
• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端
• 窗口大小字段越大, 说明网络的吞吐量越高
• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端
• 发送端接受到这个窗口之后, 就会减慢自己的发送速度
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端

1.7 拥塞控制

• 如果在刚开始阶段发送大量的数据, 会引发大量问题

• 拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载

  1.7.1 慢启动与拥塞避免

• 慢启动的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
  

• TCP开始启动的时候, 慢启动阈值等于窗口最大值

• 拥塞避免是指把拥塞窗口设置为线性规律增长，使网络较不容易出现拥塞

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

• 少量的丢包, 仅仅触发超时重传; 大量的丢包, 我们就认为网络拥塞

• 当TCP通信开始, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降

• 拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的一种方案

1.7.2 快重传和快恢复

• 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢启动阈值门限减半。但是接下去并不执行慢开始算法。
• 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将拥塞窗口设置为慢启动阈值的大小，然后执行拥塞避免算法

1.8 TCP计时器

重传计时器：
目的：为了控制丢失的报文段或者丢弃的报文段。这段时间为对报文段的等待确认时间。
创建时间：在TCP发送报文段时，会创建对次特定报文段的重传计时器。
可能发生的两种情况：在截止时间（通常为60秒）到之前，已经收到了对此特定报文段的确认，则撤销计时器；在截止时间到了，但为收到对此特定报文段的确认，则重传报文段，并且将计时器复位。
重传时间：2*RTT（Round Trip Time，为往返时间）
坚持计时器：
目的：主要解决零窗口大小通知可能导致的死锁问题
死锁问题的产生：当接收端的窗口大小为0时，接收端向发送端发送一个零窗口报文段，发送端即停止向对端发送数据。此后，如果接收端缓存区有空间则会重新给发送端发送一个窗口大小，即窗口更新。但接收端发送的这个确认报文段有可能会丢失，而此时接收端不知道已经丢失并认为自己已经发送成功，则一直处于等待数据的状态；而发送端由于没有收到该确认报文段，就会一直等待对方发来新的窗口大小，这样一来，双方都处在等待对方的状态，这样就形成了一种死锁问题。如果没有应对措施，这种局面是不会被打破的。为了解决这种问题，TCP为每一个连接设置了坚持计时器。
工作原理：当发送端TCP收到接收端发来的零窗口通知时，就会启动坚持计时器。当计时器的期限到达时，发送端就会主动发送一个特殊的报文段告诉对方确认已经丢失，必须重新发送。【这个特殊的报文段就称为探测报文段，探测报文段只有1个字节的大小，里边只有一个序号，该序号不需要被确认，甚至在计算其他部分数据的确认时该序号会被忽略。】
截止期的设置：设置为重传时间的值。但如果没有收到接收端的响应，则会发送另一个探测报文段，并将计时器的值加倍并复位，直到大于门限值（一般为60秒）。在此之后，发送端会每隔60秒发送一个探测报文段，直到窗口重新打开。
保活计时器：
目的：主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后，很长时间内客户端都没有向服务器端发送数据，此时很有可能是客户端出现故障，而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则服务器端认为客户端出现故障，并会终止连接。
时间等待计时器：
时间等待计时器是在连接终止期间使用的。
当TCP关闭连接时并不是立即关闭的，在等待期间，连接还处于过渡状态。这样就可以使重复的FIN报文段在到达终点之后被丢弃。
时间设置：一般为报文段寿命期望值的2倍。

2、UDP(用户数据报协议)

2.1 报文结构

源端口号:源主机的应用程序使用的端口号。
目的端口号:目的主机的应用程序使用的端口号。
UDP长度:是指UDP头部和UDP数据的字节长度。因为UDP头部长度为8字节，所以该字段的最小值为8。
**UDP校验和:**该字段提供了与TCP校验字段同样的功能;该字段是可选的。

2.2 UDP特点

• 无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接
• 不可靠:没有确认机制，没有重传机制；如果因为网络故障该段报文无法送达对方，UDP协议也不会给应用层返回任何错误信息