网络传输层协议：UDP和TCP

背景知识

再谈端口号

端口号(Port)标识了一个主机上进行通信的不同的应用程序；

在TCP/IP协议中, 用 "源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信(可以通过 netstat -n查看); 

端口号范围划分

0 - 1023: 知名端口号, HTTP, FTP, SSH 比特科技 等这些广为使用的应用层协议, 他们的端口号都是固定的.

1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的.

认识知名端口号(Well-Know Port Number)

ssh服务器, 使用22端口

ftp服务器, 使用21端口

telnet服务器, 使用23端口

http服务器, 使用80端口

https服务器, 使用443

端口号配置文件可以在/etc/services文件查看

netstat

netstat是一个用来查看网络状态的重要工具.

语法：netstat [选项]

功能：查看网络状态

常用选项：

n 拒绝显示别名，能显示数字的全部转化成数字

l 仅列出有在 Listen (监听) 的服务状态

p 显示建立相关链接的程序名

t (tcp)仅显示tcp相关选项

u (udp)仅显示udp相关选项

a (all)显示所有选项，默认不显示LISTEN相关

pidof

在查看服务器的进程id时非常方便.

语法：pidof [进程名]

功能：通过进程名, 查看进程id

xargs：将管道内容拼接到当前指令之后

pidof [任务名]  |  xargs   kill -9

UDP协议

UDP协议端格式

 16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度;

如果校验和出错, 就会直接丢弃;

UDP的特点

类似于发快递：

无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;

不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层 返回任何错误信息;

面向数据报: 不能够灵活的控制读写数据的次数和数量;（整发整取）

面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;

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

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

然而64K在当今的互联网环境下, 是一个非常小的数字. 如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

TCP协议

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

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

32位序号/32位确认号: 控制数据接收和发送;

为什么要有32位序号/32位确认号？

以为TCP是全双工通信。

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

6位标志位（决定TCP报文类型）:

URG（带外数据）: （如果数据想插队，越过缓冲区直接被读取）紧急指针（在有效载荷中的偏移量，只有一个字节是紧急数据）是否有效

ACK: 确认数据是否收到（正常通信都会置1）

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

RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段（服务器重启后，客户端发送报文，服务端发带RST的报文，链接复位）

SYN: 请求建立连接（请求握手）; 我们把携带SYN标识的称为同步报文段

FIN: 断开连接请求, 我们称携带FIN标识的为结束报文段

16位窗口大小: 填入自己的接收缓冲区剩余空间大小，流量控制

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

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

40字节头部选项: 暂时忽略;

send和recv通过设置MSG_OOB读取/发送带外数据。

序号是发送端发送的数据段的序号（1~1000，就发1），确认序号是应答收到的数据段的序号+数据大小.（确认序号就是确认你在这个序号之前的数据都被我收到了）

超时重传机制(解决丢包问题)

超时没有接收到ACK应答有两种情况：

1.真的丢了

真的丢了也分为两种情况，正常数据段丢了或者确认数据段丢了。如果是正常数据段丢了，再发一次就行，如果是ACK应答丢了，再发一次之后，接收端再发一次ACK应答就行。

2.还在路上

如果是还在路上，那么重发会产生数据重复问题。

接收端会检验数据段的32位序号，如果重复就丢弃。

超时时间为(2^n) * 500ms

三次握手

为什么是三次握手？

因为链接需要被管理，先描述后组织，维护一个链接有时间成本和空间成本。

一次握手和两次握手可能会有SYN洪水，三次握手是验证全双工通信通畅的最小成本。

四次挥手

如果服务端出现大量的close_wait有两种可能：

1.没有close文件描述符

2.服务器有压力

主动断开连接的乙方为什么要维持一段时间（2 * MSL（60s））的TIME_WAIT状态?

1.保证最后一个ACK被收到

2.有可能在断开时，网络中有滞留的报文

当端口处于TIME_WAIT状态就不能被绑定，要解决这个问题只要在绑定套接字之前加入下面的代码就行：

socklen_t t = 1;
setsockopt(_listen_sock, SOL_SOCKET, SO_REUSEADDR, &t, sizeof(t));

四次挥手也有可能变成三次挥手。

滑动窗口（类似于环形队列）

 既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时 间重叠在一起了).

 那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论.

情况一: 数据包已经抵达, ACK被丢了.

只要最新的ACK（同时确认前面的数据都被成功接收）应答被收到，就可以忽略前面丢失的ACK 。

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

当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001" 一样;

如果发送端主机连续三次收到了同样一个 "1001" 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;

这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已 经收到了, 被放到了接收端操作系统内核的接收缓冲区中; 

流量控制

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

流量控制是通过控制发送缓冲区的滑动窗口大小实现的：

滑动窗口 = min(拥塞窗口， 接收端缓冲区剩余空间)

拥塞控制

网络拥塞状态：由于网络拥堵，发送的报文大量丢失。

少量丢失报文可以通过超时重传机制解决，但如果从宏观来看，由于网络原因造成网络拥塞状态，就不能简单重传。如果只是简单重传只会加重网络拥堵的状况。

为了解决这个问题：TCP引入 慢启动机制, 先发少量的数据,探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

拥塞窗口是一个数字，一开始为1.

 ssthred(慢启动阈值)，拥塞窗口达到ssthred之后线性增长，当线性增长到拥塞状态时，更新拥塞避免阈值，更新ssthred为拥塞避免阈值的一半。

延迟应答

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

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

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

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

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

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输 效率; 那么所有的包都可以延迟应答么? 肯定也不是;

数量限制: 每隔N个包就应答一次;

时间限制: 超过最大延迟时间就应答一次;

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

捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 "一发一收" 的. 意味着客户端给服务器说 了 "How are you", 服务器也会给客户端回一个 "Fine, thank you";

那么这个时候ACK就可以搭顺风车, 和服务器回应的 "Fine, thank you" 一起回给客户端

面向字节流

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

写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;

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

粘包问题

tcp的报文需要自己设置协议去把数据包分开。

那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.

1.  对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;

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

3.  对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔 符不和正文冲突即可);

理解 listen 的第二个参数

对于服务器, listen 的第二个参数设置为 2, 并且不调用 accept

 

 

客户端状态正常, 但是服务器端出现了 SYN_RECV 状态, 而不是 ESTABLISHED 状态 这是因为, Linux内核协议栈为一个tcp连接管理使用两个队列:

1. 半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）

2. 全连接队列（accpetd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）

而全连接队列的长度会受到 listen 第二个参数的影响. 全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了. 这个队列的长度通过上述实验可知, 是 listen 的第二个参数 + 1.