UDP协议与TCP协议

---

前言

---

一、端口号

所谓的端口，就好像是门牌号一样，客户端可以通过ip地址找到对应的服务器端，但是服务器端是有很多端口的，每个应用程序对应一个端口号，通过类似门牌号的端口号，客户端才能真正的访问到该服务器。为了对端口进行区分，将每个端口进行了编号，这就是端口号。端口号(Port)标识了一个主机上进行通信的不同的应用程序。

在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看)。源ip+源端口号标识互联网中的唯一一个进程，目的ip+目的端口号也标识互联网中的唯一一个进程。

端口号范围划分

0 - 1023：知名端口号，HTTP，FTP，SSH等这些广为使用的应用层协议，它们的端口号都是固定的。

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

我们在写程序时应该避免使用知名端口号，因为那样会产生端口号冲突，即就造成了一个端口号被多个进程bind，这是肯定不可以的，因为这样就无法通过端口号唯一标识主机上的进程了。
但是我们可以让一个进程bind多个端口号，即一个进程可以创建多个套接字，每个套接字bind一个端口号。

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

有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号：

• ssh服务器, 使用22端口
• ftp服务器, 使用21端口
• telnet服务器, 使用23端口
• http服务器, 使用80端口
• https服务器, 使用443

执行下面的命令, 可以看到知名端口号。services这个文件其实就是一个配置文件，里面记录了端口号的映射关系。

cat /etc/services

netstat命令

netstat是一个用来查看网络状态的重要工具。
语法：netstat [选项]
功能：查看网络状态
常用选项：

• n 拒绝显示别名，能显示数字的全部转化成数字
• l 仅列出有在 Listen (监听) 的服務状态
• p 显示建立相关链接的程序名
• t (tcp)仅显示tcp相关选项
• u (udp)仅显示udp相关选项
• a (all)显示所有选项，默认不显示LISTEN相关

//有些信息需要有权限才可以查看
sudo netstat -ntap

pidof命令

在查看服务器的进程id时非常方便。
语法：pidof [进程名]
功能：通过进程名, 查看进程id

我们之前查看一个进程的进程id需要使用ps -axj命令，然后还需要使用grep命令来进行进程名的查找。这样来查看进程id是很麻烦的。此时我们就可以通过pidof命令后面跟上进程名来直接获取进程的pid。

//获取HttpServer进程的pid
pidof HttpServer

我们还可以使用xargs来将pidof命令输出的进程pid转化成为命令行参数。

下面为我们通过xargs将ls命令输出的内容转化为touch命令的命令行参数，所以我们看到当前目录下的文件的时间都改为当前时间了。

二、UDP协议

UDP协议介绍

我们前面写的关于网络的程序，其实都是在网络模型的应用层中实现的这些程序。例如我们在聊天程序中向套接字中写入数据，然后数据就被发送到了服务器端，然后服务器端也向套接字中写数据，客户端就可以从套接字中读取数据。但是这些数据在底层是怎样从客户端到服务器的呢？这其实就需要应用层调用操作系统提供的系统调用接口将数据写到传输层中，然后传输层进行数据传递。

我们在前面也说了write、send、read、recv等系统调用接口的本质其实是拷贝函数。这些函数将应用层的数据拷贝到传输层的缓冲区中，然后由传输层将这些数据再进行向下传递。

下面我们来看传输层中的UDP协议是怎样实现数据封装(分离)和发送的。
下面的就为UDP协议端格式。

因为UDP协议是面向数据报的。应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并。
例如用UDP传输100个字节的数据:
如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节。
我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。然而64K在当今的互联网环境下, 是一个非常小的数字。如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装。

在UDP协议中，当传输层接收到应用层发过来的报文后，传输层会在报文前面加一个UDP报头，该UDP报头占8个字节，其中2个字节(16位)记录了源端口号，2个字节记录目的端口号，另外还有2个字节记录UDP长度, 这个UDP长度表示整个数据报(UDP首部+UDP数据)的最大长度，最后2个字节记录这个报文的效验和，如果校验和出错, 就会直接丢弃这个报文。

UDP报文在分离有效数据时先取出这个报文的前8个字节，即取出UDP报头，然后读取该报头中记录的UDP长度，这样就知道该报文的有效数据大小，然后在取有效数据时，读取相应大小的字节数据即可。然后从UDP报头中读取目的端口号，根据这个16位目的端口号进行向上交付有效数据，即将有效数据交付给bind了这个目的端口号的进程。通过上面的过程我们就明白了在前面写应用层的程序时，为什么将端口号使用uint16_t类型来保存，因为在UDP协议中就使用了16位来保存端口号。
下面我们来分析UDP协议中怎样实现从UDP报文中提取出来有效数据和UDP报头中存的数据的。UDP的报头实际就是一个结构体，该结构体中使用了位段来使每个成员变量占16位。

struct udp_hdr
{
	uint32_t src_port : 16;  //源端口号
	uint32_t dst_port : 16;  //目的端口号
	uint32_t udp_len : 16;   //UDP报文长度
	uint32_t udp_check : 16;   //UDP效验和
};

UDP特点

UDP传输的过程类似于寄信。

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

UDP的缓冲区

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

UDP协议的socket既能读, 也能写, 这个概念叫做全双工。

基于UDP的应用层协议

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

当然, 也包括我们写的UDP程序中自定义的应用层协议。

三、TCP协议

TCP协议介绍

TCP全称为 “传输控制协议(Transmission Control Protocol”)，所以TPC协议需要对数据的传输进行一个详细的控制。
下面我们来看TCP协议段格式。

下面我们来分析TCP协议是如何进行交付和如何解包的。TCP报头有固定大小的20字节，这20字节空间中存的数据如上图所示，TCP报头中还有一个选项也是属于TCP的报头，但是这个选项的长度是可变得，不在20字节中。如果要知道TCP报头的总大小，可以通过20字节里面的4位首部长度(数据偏移)来获取，首部长度只有4字节，那么就只能表示[0,15]范围内的大小，但是这样的话首部长度就不能记录超过15的数字了，所以将首部长度的单位为4字节，那么首部长度就能表示0到60字节范围内的数据。而因为TCP固定报头已经有确定的20字节了，所以4位首部长度范围取值范围为[5,15]（[20,60]字节），二进制为[0101,1111]。
所以TCP在分离有效数据时，先读取20字节大小的标准报头，然后从中提取4位首部长度，然后乘4得到TCP报头的大小。如果结果等于20字节，那么说明这个TCP报头中没有选项；如果结果大于20字节，那么说明这个TCP报头中有选项。接下来将结果-20得到TCP报头中选项的大小，然后将TCP的报头的选项读取完，后面的就是有效数据了。需要注意的是TCP报头中是没有记录整个报文的大小的。

TCP可靠性

我们来通过下面的一个案例理解TCP的可靠性。
当小花向小王发送一条消息后，并不能确认小王收到了这条消息，但是如果小花接收到了小王的应答，那么小花就能确定上一条消息小王一定收到了，然后小王才能发回来应答。但是此时小王是不能确认自己发送的消息是否被小花收到了。此时如果小花收到应答后再次向小王发送一条消息，那么小王就能确定上一次自己发给小花的消息一定被小花收到了。虽然小花和小王不能在发送消息后第一时间确认自己的消息是否被对方收到，但是可以在收到对方的应答时确定自己的上一条消息一定被对方收到了。

在实际中，客户端会向服务器发送多个报文，服务器也会返回多个应答，那么客户端如何确认哪一个应答对应哪一个请求？即客户端发送请求的顺序不一定是收到应答的顺序。那么这就要通过TCP协议报头中的32位序号和32位确认序号来保证顺序了。
TCP报头的序号就为1000、2000、3000等，表示这一次发送的序号。服务器发送的应答中TCP报头的确认序号会被修改为1001、2001、3001。确认序号对应的数字表示之前所有的报文已经全部收到了，告诉客户端下一次发送报文从确认序号指定的序号开始发送。并且有了序号后，就算客户端发送给服务器的报文出现了乱序，那么服务器也可以根据每个报文的报头中的序号将报文进行排序，即2000 1000 3000 -> 1000 2000 3000

这样看TCP报头中只需要一个32位的序号来记录发送序号和确认序号就可以了，为什么需要两个32位的字段呢？这是因为TCP为全双工的，任何一方既可以收也可以发送。有可能客户端给服务器发送消息后，服务器在发送确认报文给客户端的同时，服务器也想要向客户端发送数据，那么这时就需要服务器发送的报文的报头中，32位序号用来记录这次发送给客户端的消息的序号，32位确认序号用来给客户端应答，告诉客户端确认序号之前的报文都收到了。所以TCP报头中有两个32位字段来表示序号和确认序号，因为TCP工作方式都为全双工的，在发送确认的同时也可能携带数据。
下面我们来看TCP协议可以全双工通信的原理。
TCP有发送缓冲区和接收缓冲区。

16位窗口大小

上面我们说了TCP协议中客户端和服务端都有发送缓冲区，接收缓冲区。我们知道通常一个服务器需要处理很多客户端的请求，那么当客户端发送数据太快时，如果服务端的接收缓冲区已经满了，此时服务端就来不及接收客户端发送的数据了，此时就需要告诉客户端发送数据慢一些，但是也不能太慢，这个就是流量控制。那么服务端该怎样告诉客户端自己的情况呢，服务端只需要发送一个响应给客户端即可，该响应的报头中使用16位窗口大小来记录服务端的接收能力，而服务端的接收能力可以通过服务端的接收缓冲区中剩余空间的大小而反应出来，所以16位窗口大小就记录了发送报文的一方的当前接收缓冲区中剩余空间的大小的。

6个标志位

6个标志位就用了表示该报文的一些信息。详细文章

我们先来看下面三个标志位的含义。

标志位	含义
SYN	该报文是一个连接请求报文
FIN	该报文是一个断开连接请求的报文
ACK	确认应答标志位，凡是该报文具有应答特征，该标志位都会被设置为1。大部分网络报文的ACK都是被设置为1的，只有第一个连接请求报文ACK不为1

操作系统层面的连接

每一个服务端都会接收到很多客户端发来的请求，那么就会有大量客户端和服务端建立连接，所以服务端就会存在大量的连接。那么操作系统就需要将这些连接使用一种数据结构描述出来，然后通过管理这些数据结构对象来管理连接。即连接的本质其实就是内核的一种数据结构类型，建立连接成功的时候就是在内存中创建对应的连接对象，然后对多个连接对象进行某种数据结构的组织。这样操作系统管理连接就类似于管理进程，文件了，所以管理连接操作系统也是需要付出内存和CPU负载的成本的。那么我们就知道了服务端的操作系统中是不能有太多连接的，因为一旦连接将操作系统的内存空间占的太多，那么操作系统可能就会因为内存不够而崩溃。

三次握手

下面我们来看一下TCP协议中的三次握手。
客户端会先向服务端发送一个标志位SYN有效的请求建立连接的报文，发送完这个报文后客户端的状态就为SYN_SENT状态。然后服务端收到了客户端发送的请求建立连接报文，服务端也会发送一个标志位SYN有效的报文来建立连接，并且服务端还会将这个报文的ACK也为有效，因为这个报文也是个确认报文，用来告诉客户端上一个请求服务端接收到了。当服务器将标志位SYN和ACK有效的报文发送后，服务端的状态就为SYN_RCVD。当客户端收到服务端发送过来的标志位SYN和ACK有效的报文后，客户端就知道了上一个请求建立连接的报文服务端收到了，然后客户端再向服务端发送一个标志位ACK有效的报文，告诉服务端收到了建立连接报文。然后客户端此时的状态就为ESTABUSHED了。然后当服务器收到了客户端发送的ACK确认报文后，服务端就知道了自己发送的报文被客户端收到了，那么此时服务端也将自己的状态变为ESTABUSHED。这就是一次完整的TCP三次握手。

下面我们来看三次握手的一些问题。三次握手对客户端和服务器都要起效，即客户端和服务器都通信了三次。客户端两次发送一次接收。服务器两次接收一次发送。
三次握手并不能一定保证成功，因为最后一次客户端向服务端发送ACK确认报文时并不能确定是否发送成功。所以三次握手当ACK确认报文成功发向服务端后才算成功。

那么为什么要是三次握手呢？一次、两次、四次不可以吗？
因为如果是一次握手的话，那么当客户端向服务器发送一个SYN建立连接报文后不需要维护这次连接就可以再向服务端发送另一个建立连接报文，那么客户端就不会有管理连接的开销，但是服务端每当收到一个客户端发送的建立连接的请求，服务端都要为每个连接建立数据结构进行管理。那么如果一个客户端死循环向服务端发送建立连接报文，那么服务端就会为每个连接建立数据结构，这样服务端的内存很快就会用完，所以一次握手的话，如果客户端使服务器崩溃是很简单的。
而两次握手的话，就是当客户端发送给服务器标志位SYN有效的建立连接报文后，服务端收到这个报文后给客户端发送一个ACK确认报文，但是这样的话客户端还是不需要维护这一次连接，因为服务端没有向客户端发送标志位SYN有效的建立连接报文。这样的话一个客户端还是可以完成死循环向服务端发送建立连接报文来使服务端崩溃。

如果是四次握手的话，那么先建立并维护连接的又是服务端了，即服务端建立好连接后，发送给客户端，然后客户端再将建立好的连接关闭，此时服务端也不知道，并且服务端已经建立好连接并在维护了。即已经占用了服务端的资源维护连接了。所以客户端还是可以通过一台主机来使服务端崩溃。
所以TCP协议采用三次握手。这样三次握手的话需要客户端先建立好连接，然后服务器收到客户端发送的ACK确认报文后才会建立连接，这样客户端就需要和服务器有同样的开销维护连接了，那么此时一台客户端就不能通过死循环发送连接请求来使服务器崩溃了。而且三次握手还可以验证全双工，即三次握手后客户端和服务端都进行了一次完整的发送请求，然后收到确认报文的过程，这样就保证了客户端和服务器都具有发送报文并且接收确认报文的能力。

当服务器重启时，此时服务端上维护的连接就会都没有了，但是客户端此时还认为与服务器建立了连接，继续通过这个连接向服务端发送数据，这样的情况是肯定不可以的，所以就有了RST标志位，RST表示复位标记位，用于非正常的关闭连接。客户端因为主机崩溃或者网线断开，但是服务端认为对方还在。如果服务端长时间没有收到对方的数据，就会定期发送报文询问对方是否在线；客户端收到以后，由于连接不存在，此时就会发送携带RST标志位的报文来间接告诉服务端连接异常。

然后我们再来看PSH标志位，当客户端和服务端发送报文时，都会通过16位窗口位来告诉对方自己当前的接收缓冲区中剩余的空间大小，但是因为服务端会和很多客户端建立连接，所以服务端的接收缓冲区可能会出现快满或者已经满的情况，此时客户端就可以发送PSH报文来督促服务端尽快将接收缓冲区的数据进行向上交付。PSH表示催促标记位，可以理解为Push。Client在不断发数据，Server在不断接收数据同时在给Client发送应答，应答报文中包含了16位窗口大小的字段，其实就是在告诉Client自己接收缓冲区剩余空间的大小，以便于Client及时调整自己的发送速度。但是，Server接收缓冲区快满了或者说已经满了，此时Client给在发送的报文里设置PSH标记位来催促对方尽快取走缓冲区的数据。

我们再来了解URG标志位，URG表示紧急标记位。当发送方希望一些数据尽快被接收方的上层拿到的时候，就需要用到这个标记位。通常需要搭配16位紧急指针使用，要传递的紧急数据混在普通数据里，16位紧急指针指明了紧急数据在普通数据中的具体位置。如果URG为0，那么就表示服务器按序读取报文，如果URG为1，那么此时紧急指针就有用了。紧急指针为一个偏移量，记录了紧急数据在这个TCP报文中的偏移量。例如偏移量为50，那么这个TCP报文的第50个字节这一个字节的数据就是紧急数据。注意：紧急数据一般只能传递（或者说占用）一个字节，因为大多数情况下，报文都是按序到达然后被读取的，如果紧急数据太多，读取的时间太长，会破坏TCP按序到达的特性。

四次挥手

客户端向服务端发送FIN断开连接报文，然后客户端状态变为FIN_WAIT_2，服务端收到断开连接报文后向客户端发送ACK确认报文，然后服务端将状态改为CLOSE_WAIT。当客户端收到确认报文后，客户端将状态改为FIN_WAIT_2。上面为客户端向服务端进行断开连接请求，下面再来进行服务端向客户端进行断开连接请求。服务端会向客户端发送FIN断开连接请求，然后将自己的状态变为LAST_ACK。然后客户端收到断开连接请求后，向服务器发送ACK确认报文，然后将状态改为TIME_WAIT状态。然后服务端收到ACK确认报文后，将自己的状态变为CLOSED状态，这样就完成了四次挥手。需要注意的是客户端进入到TIME_WAIT状态后，过一段时间后才会变为CLOSED状态，即主动断开连接的一方要维持一段时间的TIME_WAIT状态。这一段时间为2MSL(MSL数据进行一次通信的最大时间)，保证历史数据从网络中消散。因为历史数据可能会影响后序的客户端和服务器新建立的连接的通信。还有就是等一段时间是为了防止客户端最后发过去的ACK丢失，如果最后发给服务器的ACK丢失，那么因为服务器一直没有收到ACK，所以会进行超时重传，然后如果客户端不等一段时间直接CLOSED状态退出，那么服务器就会一直收不到客户端的ACK，然后服务器一直处于LAST_ACK状态进行超时重传。如果客户端在TIME_WAIT等一段时间，那么就算服务器超时重传FIN了，客户端还能收到，然后再次给服务器发送ACK应答报文。

TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态。
我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口。
MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s。
可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值;

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

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

下面我们来验证一个服务端容易出现的一个问题，如果我们发现服务端具有大量的CLOSE_WAIT状态的连接的时候，这可能是因为服务端的应用层写的有bug，即忘记关闭对应的连接sockfd了。下面我们来进行验证。
我们使用Sock来创建一个服务器，然后我们不关闭为每个连接提供服务端套接字sockfd。

我们看到服务器启动后，客户端连接到服务器后，服务器处于ESTABLISHED状态。当将客户端进行关闭后，服务器会进入CLOSE_WAIT状态。

因为我们没有在服务器中关闭为每个连接提供服务端套接字sockfd，所以当我们建立多个客户端再关闭后，那么服务器中就会有多个处于CLOSE_WAIT状态的连接。

如果我们在代码中将为每个连接提供服务端套接字sockfd进行关闭，那么当客户端断开与服务器的连接后，服务器就不会再有大量处于CLOSE_WAIT状态的连接了。

我们看到当客户端和服务器进行连接后，服务端有一个处于ESTABLISHED状态的连接，而当10s后服务端将sockfd关闭，那么客户端会被断开连接，然后服务端也没有了处于CLOSE_WAIT状态的连接了。

我们在前面写的关于网络的代码中，有时就会遇到将服务器关闭后不能马上重新启动的问题，这其实就是因为主动断开连接的一方需要维持一定时间的TIME_WAIT状态后才会变为CLOSED状态，即虽然在TIME_WAIT状态时，这个连接所使用的端口号等都已经不再使用了，但是因为处于TIME_WAIT状态，所以这个端口号还被记录在这次连接中，并且显示为已被占用，所以当在上一次连接处于TIME_WAIT状态时再次启动服务器就会出现bind绑定失败的错误，这是因为端口号被占用了，还没有完全释放。
在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求)。这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接。由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip, 源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的.如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题。

下面我们来进行验证。
当我们将服务器启动后，然后客户端与服务器建立连接，然后我们将服务器关闭。此时马上重新启动服务器，但是我们看到服务器并没有被启动成功，并且我们查看这一次的错误码为3。我们还看到此时服务器已经关闭了，但是还是存在一个处于TIME_WAIT状态的连接。这就是因为服务器为主动断开连接的一方，所以服务器退出后还会维持一段时间的TIME_WAIT状态，此时虽然连接已经释放，但是这次连接使用的地址信息ip、端口号port等依旧是被占用的，所以才会在重新启动服务器时报出3错误。

如果遇到上面的情况时，想要马上启动服务器，此时可以通过setsockopt接口将listensock套接字进行设置。这样服务器退出后如果处于TIME_WAIT状态，那么也可以马上将服务器重启，而不需要等待一段时间。使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个
socket描述符。

下面我们在Sock中对listensock套接字进行设置。setsockpt接口的原理就是在上一个连接还处于TIME_WAIT状态时，此时重新启动服务器，在操作系统的内核中会进行判断检查服务器bind的8080端口是否被使用。但是因为上一个连接处于TIME_WAIT状态，那么8080端口就还在被占用，所以新启动的服务器会启动不成功。而使用setsockopt后，就会让操作系统内核跳过这个检查，直接让新服务器使用8080端口。

确认应答(ACK)机制

我们在前面学习TCP报头的32位序号和32位确认序号时，已经了解了TCP协议的确认应答机制，即发送端每一次发送数据时都会为这个数据进行编号，例如1000，然后将这个编号放到报头的32位序号中。当接收端收到数据后，会发送一个确认应答的报文，这个确认应答报文的报头中的确认序号中会为1001，表示1000之前的数据都已经收到，下一次发送数据从1001开始。通过这个我们知道了TCP协议将每个字节的数据都进行了编号，即为序列号。并且每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.
我们可以将TCP协议中的发送缓冲区看作一个char sendbuffer[NUM]类型的数据。这样每一个字节的数据都有了编号。

超时重传

超时重传是TCP可靠性的体现之一。例如下面的例子中，主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B，如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。

但是还会遇到下面的情况，即主机A未收到B发来的确认应答，也可能是因为B发送的确认应答ACK丢失了。并且主机A无法区分是数据丢了，还是确认应答丢了，所以只要超时没有收到应答，那么就会进行重传。那么如果是主机B的应答一直丢的话，那么主机A一直收不到应答，就会一直超时重传，主机B就会收到多个重复数据。但是主机B可以通过序号来进行数据去重，这也是可靠性的体现。即TCP协议需要能够识别出哪些包是重复的包，并且把重复的包丢弃掉。这时候我们可以利用前面提到的序列号,，就可以很容易做到去重的效果。

上面我们就了解了超时重传的过程，那么超时的时间应该如何确定呢？这个超时重传的时间肯定不能太长也不能太短，而且还不能进行固定，因为网络好的时候，应该让超时重传的时间短一些，网络不好的时候，应该让超时重传的时间长一些。

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

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

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

流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端。
窗口大小字段越大，说明网络的吞吐量越高。
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端接受到这个窗口之后，就会减慢自己的发送速度。
如果接收端缓冲区满了，就会将窗口置为0，这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

我们知道在进行流量控制的时候，通过ACK来向对方告知自己的接收能力，那么就需要先进行交互报文才能得知对方的接收能力(接收缓冲区中剩余空间的大小)，那么第一次发送数据应该发送多少呢？这里我们就需要注意了，发送端和接收端的第一次发送数据 != 第一次交换报文。因为发送端和接收端想要进行数据交换，需要先建立连接，即进行三次握手，而三次握手时发送端和接收端进行了第一次交换报文，并且三次握手时是不携带数据的，这样发送端和接收端就可以通过三次握手来确定双方的接收能力，然后再决定自己的发送速度。发送端和接收端可以通过TCP报文首部中的16位窗口字段来告诉对方自己的接收缓冲区中剩余空间的大小。那么问题来了，16位数字最大表示65535，那么TCP窗口最大就是65535字节么?实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移 M 位。

滑动窗口

在TCP中，通常将报文称为数据段。
上面我们学习了TCP协议的确认应答机制，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差，尤其是数据往返的时间较长的时候。因为只有当收到ACK后才能发送下一个数据段，这样就相当于串行发送数据了，所以性能会比较差。

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

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

那么滑动窗口应该在哪里呢？其实滑动窗口在发送缓冲区中，即滑动窗口属于发送缓冲区的一部分，那么我们就知道了发送缓冲区中肯定有三部分数据，已经发送和收到应答的数据、滑动窗口中可以直接发送并且暂时不需要应答的数据、尚未发送的数据。滑动窗口的本质是发送方可以一次性向对方发送数据的上限，但是滑动窗口需要保证这些数据对方来得及接收，所以滑动窗口的上限和对方的接收能力是有关的。

那么当前面的数据已经收到应答后，滑动窗口是怎样向右移动的呢？
我们在前面说了可以将发送缓冲区看作应该数组，那么滑动窗口的本质：就是指针或者下标。
滑动窗口不是必须向右移动，当滑动窗口一直减小时，win_start会一直向后移动，但是win_end不变，所以滑动窗口没有右移。
滑动窗口大小可以为0。

滑动窗口中的丢包分为两种。
第一种为数据包已经抵达，但是确认应答的ACK丢了，这种情况下，部分ACK丢了并不要紧，因为可以通过后序的ACK进行确认。
当发送端发送滑动窗口的数据到接收端时，如果1001-2001的数据丢了，2001-5001的数据被接收到，但是接收端向发送端发回的2001-5001的确认应答中，都会将确认序号设置为1001，因为1001-2001的数据接受端没有收到。如果发送端发送的1001-2001接收端收到了，2001-3001接收端没有收到，3001-5001接收端收到了，那么接收端发送的确认应答中，都会将确认序号设置为2001。这样的话在发送端中每次收到确认应答时会将win_start等于确认应答的确认序号，如果有的数据接收端没有收到，发送端也不会跳过这个丢失的数据，而是将丢失的数据进行重新发送。那么如果将发送缓冲区当作一个数组，滑动窗口一直向右滑动，不会出现越界问题吗？TCP的发送缓冲区是环状的，不会出现越界问题。

第二种情况为数据包就直接丢了
当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001” 一样;
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中。
这种机制被称为 “高速重发控制”(也叫 “快重传”).

拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的。TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

此处引入一个概念程为拥塞窗口
发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
所以我们前面说的滑动窗口的大小其实为min(拥塞窗口，对方窗口大小(接收能力))。

像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.

为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。所以TCP协议中的慢启动算法中前期使用指数增长，中后期使用线性增长。这个算法可以缓解网络拥塞问题，也可以尽快恢复双方通信的效率。

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小，因为当接收方接收到一个数据后，接收缓冲区的剩余空间肯定更小了，所以ACK中记录的窗口大小也会变小。
例如：

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

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

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

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

捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”; 那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端。捎带应答就是将要发送给对方的ACK报文和发送给对方的数据报文合为一个。

面向字节流

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

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

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

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

粘包问题

首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包。
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段。
站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中。
站在应用层的角度, 看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包。

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

对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置。
对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可)。

对于UDP协议来说, 是否也存在 “粘包问题” 呢?

对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界。
站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况。

TCP异常情况

当将连接建立好了之后，如果进程终止和机器重启，那么这个连接是会正常进行4次挥手的。

进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别。
机器重启: 和进程终止的情况相同。

如果断网或者断电，那么这个主机就没有机会向对方进行4次挥手。所以对方主机刚开始还会认为连接存在，但是对方主机中会定期发报文询问对方是否还在，如果不在，那么就知道主机异常断网了，然后就会将自己和这个主机的连接释放。

机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放。
另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接。

TCP小结

为什么TCP这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能.
可靠性:

校验和
序列号(按序到达)
确认应答
超时重发
连接管理
流量控制
拥塞控制

提高性能:

滑动窗口
快速重传
延迟应答
捎带应答

其他:

定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)

基于TCP应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP
当然, 也包括我们自己写TCP程序时自定义的应用层协议;

TCP/UDP对比

我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较。

TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播;

理解 listen 的第二个参数

我们通过对TCP的学习知道了建立TCP连接需要先创建套接字，然后进行bind绑定，并且让服务器处于监听状态，当有连接后，就使用accept接口来建立连接。其实当使用accept接口建立连接时，这个连接操作系统已经在底层建立好了，而accept接口只是从底层获取这个操作系统建立好的连接，所以accept不需要参与三次握手的过程。既然需要先建立好连接，然后accept接口才能获取对应的连接，那么操作系统底层建立连接时，自然不需要accept接口函数也可以建立成功了。我们可以认为连接是底层建立好的，而accept只是将建立好的连接拿过来使用。那么如果当我们写的应用层程序中，来不及调用accept接口来获取连接，并且此时多个客户端还一直发送建立连接的请求，那么我们需要先将每个连接都先建立好吗？这肯定是不行的，因为建立连接是需要消耗的。所以操作系统就需要维护一个连接队列，这个队列不能没有，如果没有的话，那么当accept来不及获取底层连接时，客户端就无法和服务器建立连接了，这是不行的。而且这个队列也不能太长，如果太长的话客户端还需要等很长时间。这个队列的长度就和listen接口函数的第二个参数有关。

下面我们来验证服务器不使用accept接口时，连接也会建立成功。


下面我们让listen接口的第二个参数改为1。

我们看到当有三个客户端连接到服务器时，第三个连接在服务器的状态为SYN_RECV，即这个连接还没有完成三次握手。当我们再创建第四个客户端连接服务器时也会是同样的情况。这就和我们将listen接口的第二个参数设置为1有关。listen接口函数的第二个参数的意义：底层全连接队列的长度 = listen的第二个参数+1。所以我们将listen接口函数的第二个参数设置为1后，此时如果上层不调用accept接口获取连接，那么底层建立好的连接只能保持两个，只有当上层使用accept接口取走建立好的连接后，底层才会建立新的连接等待accept接口取走。