一、端口号

1.什么是端口号

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

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

服务器的同一个服务会使用多进程或者多线程的方式，对于不同的客户端请求同一个服务器的同一个端口号，此时服务端会根据IP地址进行辨别是哪一个客户端发起的请求，而对于同一个客户端(浏览器打开两个页面访问同一个服务)发起两个请求，此时会根据端口号来进行辨别。

2.端口号范围划分

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

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

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

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

ssh 服务器, 使用22端口

ftp 服务器, 使用21端口

telnet 服务器, 使用23端口

http 服务器, 使用80端口

https 服务器, 使用443

执行下面的命令, 可以看到知名端口号

cat/vim /etc/services

我们自己写一个程序使用端口号时, 要避开这些知名端口号

这里有两个问题：

1.一个进程是否可以bind多个端口号?

2.一个端口号是否可以被多个进程bind?

我们知道，数据是自底向上进行传输的，所以要保证端口号到进程的唯一性，所以一个端口号只能被一个进程bind，而一个进程可以bind多个端口号，比如bind两个端口号，一个用来传输数据，一个用来传输指令。

4.netstat

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

语法：netstat [选项]

功能：查看网络状态

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

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

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

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

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

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

5.pidof

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

语法：pidof [进程名]

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

二、UDP协议

1.UDP协议端格式

我们学习协议的时候，需要分出报头和有效载荷，回答如何进行解包(如何将报头和有效载荷进行分离)以及如何进行分用

UDP采用固定报头的方式，报头占用8个字节，剩下的都是有效载荷，比如我们在应用层发送的"你好"就会保存在UDP的数据中。

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

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

我们知道，Linux内核是用C语言写的，而报头是OS层面定制的协议，所以所谓的报头其实就是一种结构化数据对象。对于UDP的报头我们可以采用如如下的结构体或者位段进行表示(伪代码)

// 结构体
struct udp_hdr
{
    uint16_t src_port;
    uint16_t dsc_port;
    uint16_t length;
    uint16_t check;
};

// 位段
struct udp_hdr
{
    unsigned int src_port:16;
    unsigned int dsc_port:16;
    unsigned int length:16;
    unsigned int check:16;
};

对于数据的向下进行封装的过程我们可以采用如下伪代码进行表示：

char* hdr = malloc(XXXX);// 为报头开辟空间
char* message;//应用层传下来的数据
char* start = hdr + sizepf(udp_hdr);//指向有效载荷地址的开始
strcpy(start,message,strlen(message));//将数据拷贝到有效载荷的空间中
// 设置报头的属性
(struct udp_hdr)hdr->src_port = XXX;
(struct udp_hdr)hdr->dsc_port = YYY;
(struct udp_hdr)hdr->length = XXXX;
(struct udp_hdr)hdr->check = ZZZ;

这样就完成了数据从应用层但传输层的封装。

2.UDP的特点

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

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

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

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

3.面向数据报

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

用UDP传输100个字节的数据

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

就像我们收取快递一样，假如有5个快递，我们不能先取一个半。

4.UDP的缓冲区

在谈UDP缓冲区之前，我们先谈谈缓冲区(以TCP缓冲区为例)

我们知道我们的网络IO接口，其实并不是发送和接收接口，而是拷贝接口。

我们在网络发送数据的时候，在应用层调用send/write接口并不是将数据发送到网络中，而是先将数据从应用层缓冲区拷贝到传输层中的发送缓冲区中(这就是为什么我们在调用send/write函数的时候，需要先定义一个应用层缓冲区)，函数调用完毕之后就返回了，这样就大大节省了应用层的时候，然后再由OS决定什么时候将数据发送到网络中，数据丢失了怎么办等等。之后将数据发送到接收方的接收缓冲区中，然后再调用read/recv函数将数据从接收缓冲区中拷贝到应用层的缓冲区中(这就是为什么我们调用read/recv函数之前，需要先使用一个buffer这样的应用层缓冲区)。

由于双方都有一对发送和接收缓冲区，所以就可以在发送数据的同时，又可以从接收缓冲区中读取数据，就有的通信方式为全双工。所以缓冲区既节省了应用层的时间，又使用了全双工通信。

UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;

UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;

UDP的socket既能读, 也能写, 也可以实现全双工通信

5.UDP使用注意事项

我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。然而64K在当今的互联网环境下, 是一个非常小的数字。如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装。

6.基于UDP的应用层协议

NFS: 网络文件系统

TFTP: 简单文件传输协议

DHCP: 动态主机配置协议

BOOTP: 启动协议(用于无盘设备启动)

DNS: 域名解析协议

当然, 也包括你自己写UDP程序时自定义的应用层协议。

对于域名解析协议，比如我们在搜索www.baidu.com的时候，是由域名服务器将www.baidu.com解析成ip地址返回之后再访问百度的服务器，对于这种用途我们使用UDP即可，不需要TCP的重传等待机制。

三、TCP协议

1.TCP协议段格式

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

1.1理解封装解包和分用

对于协议。我们先理解如何封装解包，如何进行分用

tcp协议是由标准长度的–20字节，那么我们就可以先读取20字节，然后将其转化为结构化的数据，读取标准报头中的4位首部长度，就能得到后续报头的剩余大小。首位长度占4个字节，取值范围为0-15，TCP报文的总长度 = 4位首部长度 * 4字节，所以TCP报文的总长度的取值范围是20-60字节。

我们举一个例子，假如我们报头为20字节，那么4位首部长度应该填多少呢？x*4字节 = 20 x = 5(0101)，所以4为首部长度填0101

所以我们只要把TCP报头处理读取完毕，剩下的就是有效载荷。

TCP的报头里面，为什么没有有效载荷的长度呢？

因为TCP是面向字节流的，我们读取到下一个报头就表示这个报文已经读取完毕了

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去，所以有了目的端口号，就可以找到对应的进程了，数据就可以交互给进程了。

我们收到一个报文，是如何找到曾经bind特定port进程的？网络协议栈和文件是什么关系？

我们系统中很多的场景需要我们快速定位一个进程，那么我们如何通过port来定位一个进程呢，OS系统中维护了一张port作为key值，PCB作为value值的哈希表，此时我们就能够很快的通过port找到对应的进程。

通过port找到对应的进程之后，PCB有对应的文件描述符表–file_struct，通过上层的sock 就能找到对应的struct file文件，而struct file有自己的读写缓冲区，TCP传输层将数据拷贝到该文件的读写缓冲区中，供上层进行读取(调用read/recv等)

我们如何理解TCP报头呢

TCP的报头也是一个结构化的数据，和UDP一样，可以使用一个结构体或者位段进行表示：

struct tcp_hdr
{
    uint32_t src_port:16;
    uint32_t dst_port:16;
    uint32_t seq;
    uint32_t ack_seq:16;
    uint32_t header_length:4;
    .....
};

然后我们在封装的时候，在有效数据前加载对应的报头即可，和UDP类似。

至此就完成了封装解包以及分用的过程

1.2 序号与确认序号

下面我们来谈谈TCP的可靠性和提高传送效率的问题

我们知道在网络传输的时候，会存在不可靠的问题，这样因为传输距离变长了

我们知道在内存和外设之间是用"线"连接起来的，称为IO总线，内存和CPU也是用"线"连接起来的，该线称为系统总线。此外，内存和外设之间进行通信的时候，也有自己的协议，来进行控制外设，这就是嵌入式。那么在内存，CPU和外设进行通信的时候，为什么没有谈论可靠性的问题呢，这是因为他们的距离特别的近。我们可以想象一下，我们把这些"线"拉到很远的地方，不就变成了网络通信了吗。

不可靠问题常见的有以下场景:丢包，乱序(发送顺序和接收顺序不一致),校验错误(比特位丢失，翻转等等)，重复(发送方以为数据丢失，导致重复发送)

如果距离变长了，此时就不存在了绝对的可靠性。

比如两个相隔500米，一个问"你吃饭了吗"，另一个回答说"我吃了"，那么第一个人就能确定另外一个人接收到了信息，然后你说"你既然吃了，我们一起去玩耍吧"，然后又继续等待对方的回应。

虽然远距离传输不存在绝对的可靠性，但是存在相对的可靠性，一个报文只要收到了应答就能保证报文的可靠性。

所以我们认为，只有收到了应答，历史信息我才能100%确认对方收到–确认应答了，才算可靠

双方通信，一定存在最新的数据，没有应答–最新消息一般无法保证可靠性

TCP收发消息的时候的工作模式

无论是客户端向服务端，还是服务端向客户端法消息，都需要有应答，这样才能保证两个朝向的可靠性，双方在进行通信的时候，可能除了正常的数据段，通信时也会涵盖确认数据段

双方通信时不一定是一个发信息之后一个进行回应，而是可能客户端发送多个数据段，服务端一个一个地进行应答，此外，TCP双方的地位是对等的。

那么数据到达对方的顺序和发送顺序是一样的吗，这是不一定的。那么就需要有方式识别数据段本身。TCP使用32位序号和32位确认序号来进行标识。

确认应答 && 确认序号：接收方已经收到了ACK序号之前的所有的(真的所有，而且连续的)报文。

确认应答序号 = 序号+1，提醒对方下一次发数据时的序号

那么为什么需要有两组序号呢？这是因为TCP是全双工的，双发可能会互发消息。

1.3 16位窗口大小

我们知道，双方进行通信的时候，发送数据快了不行，慢了也不行，发送快了对方来不及接收，导致缓冲区被打满，慢了又让对方一直等待，所以发生数据的速度要合适

那么发送方如何得知，我发发送数据量是合适的，这就需要等到反馈，我们需要得到对方接收缓冲区的剩余空间的大小，OS系统使用16为窗口大小来标识剩余空间的代谢

那么在我发送的报文中写入的是我自己的剩余空间大小还是对方的呢，答案是我自己的接收缓冲区的剩余空间的大小，因为写的是对方接收缓冲区的大小，就说明我知道对方接收缓冲区的剩余空间的大小，那么就需要16位窗口大小了，此外我构建的所有的TCP报文，都是要给对方发送了，这对于客户端和服务器端都适用，这样就交换了缓冲区的接收能力，就实现了流量控制

1.4 6位标记位与16位紧急指针

我们知道，服务端每时每刻都接收到不同的客户端发送的信息，有的可能是建立链接，有的是断开连接的请求，有的是正常的数据段，有的是应答(ack)，这就决定了TCP报文也是有类型的,接收方根据不同的TCP报文，就要有不同的动作，如何标识不同的报文呢，TCP选择了6位标记位来进行标识

SYN：表示请求建立连接

FIN：表示断开连接

ACK：表示应答

PSH && URG：表示需要被特殊尽快处理的数据，催促对方让上层进行取走数据，此时URG就会被置为1，这些数据需要靠16为紧急指针来进行定位，这些数据保存在有效载荷中偏移量为16位紧急指针中内容的大小的位置处，数据的大小为1字节，这些数据被称为带外数据。我们可以发送该类数据来询问服务器的运行状态，因为服务器在处于高载荷的数据，如果使用正常的数据段，就会一直排队，很久才能得到应答，而使用带外数据就会很快得到应答，因为走的不是同一个数据流，服务器会直接进行读取该数据

数据对于接收方而言，乱序本身就是不可靠的表现，要对收到的数据进行排序，保证数据的按时到达，所以报文是有序号的，所以接收缓冲区是一个队列来进行保证

RESET：重新建立连接

我们知道TCP通信需要进行连接，那么就需要进行三次握手和四次挥手，那么三次握手和四次挥手一定成功吗，其实是不一定的，即使在连接建立成功之后，我们在通信的过程中，也有可能有连接单方面的问题，比如在通信的过程中，服务端突然断电了，一会之后再进行重启，此时服务器就会认为连接已经不存在了，而客户端却不知道，一位连接还存在，仍然继续向服务器发送信息，此时客户端就会发生没有建立连接的客户端向自己进行通信，此时服务器就会告诉客户端进行通信之前需要先进行连接，就会在TCP报文中将RESET的比特位置为1

总结：

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

32位序号/32位确认号: 后面详细讲;

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

6位标志位:

URG: 紧急指针是否有效

ACK: 确认号是否有效

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

RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段

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

FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

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

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

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

2.确认应答(ACK)机制

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

我们在上文已经讲过，应答序号 = 序号 + 1

TCP将每个字节的数据都进行了编号. 即为序列号.

为什么能够将每个字节的数据都带有编号呢？

这是因为TCP是字节流的，就可以将缓冲区当做一个字符数组，只要将数据拷贝到发生缓冲区中，每个字节就天然有了序号。

3.超时重传机制

TCP传输需要保证可靠性，如果出现了丢包，那么就需要有特定的策略来保证可靠性，比如重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;

如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发;

但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了

因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉.

这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.

1.发送方如何判定丢包了呢？

其实真正有没有丢包，发送方其实不知道，但是可以定策略，超时了就判定丢包了

2.发送端发出去的数据，被发出的数据并不是我们想象的那么立马被移除，而是必须被维持一段时间，其中被维持到发送缓冲区中

3.超时时间怎么定？是固定的吗？

超时的时间不是固定的，因为网络的状况是波动的，假如网络通畅而超时的时候设置很长，那么就会丢包了很久之后才会重传，网络不好的时候超时时间很短的话就会没有丢包被误以为丢包了，其实是还在进行发送中

那么, 如果超时的时间如何确定?

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.

但是这个时间的长短, 随着网络环境的不同, 是有差异的.

如果超时时间设的太长, 会影响整体的重传效率;

如果超时时间设的太短, 有可能会频繁发送重复的包;

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

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.

如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.

如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.

累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

4.连接管理机制

在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接

三次握手不一定非得成功，最担心的其实是最后一个ACK丢失，但是有配套的解决方案：超出时间之后客户端会进行重传。如果没有建立成功，客户端以为建立成功，直接给客户端发送消息，那么服务端会将RESET标记位置为1，让客户端进行重连

连接是需要被管理起来的，被OS管理起来，管理方法先描述，再组织，但是维护一个连接是有成本的(时间和空间成本)

为什么要三次握手？一次两次四五次行不行？

对于一次握手，那么就只要客户端发送连接请求，那么服务端就要维护已经建立好的请求，那么如果客户端不断的发起连接请求，就会出现SYN洪水，即单机就可以完成对服务器进行攻击

对于进行两次握手，在服务端只有发出ACK和SYN之后，就会认为连接建立完毕，也会发生只有一次握手的情况

对于三次握手，是用最小的成本验证了全双工通信信道是通常的，因为服务端接收到客户端的请求之后，就能说明服务器能够接收数据，服务端发送FYN和ACK之后，能表明客户端能够发送数据和接收数据，客户端发送ACK之后，就能说明服务器能够发送数据

三次握手能够有效的防止单机进行对服务器的攻击，因为客户端在发送ACK之后就认为连接建立好了，而服务端之后在接收到ACK之后才认为连接建立好了，那么客户端一定先比服务端维护好连接请求，如果客户端一直建立请求，客户端会遭受同等的维护压力成本

服务器收到攻击，本身就不应该是TCP握手解决的，但是握手有明显的漏洞，那就是TCP的问题了

对于四次挥手，挥手的前提是双方已经建立好连接之后，所以断开连接是双方的事情，需要征得双方的同意。所以一方发送FIN报文断开连接请求，另一方ACK应答，另一方再发送FIN断开连接请求，然后再ACK。最开始断开的一方不再发送数据指的是不发用户数据，并不代表底层没有管理报文的交互。不再发用户数据了TCP其实并不知道，但是用户知道，因为上传会调用close(sock)

主动断开的一方，最终的状态是TIME_WAIT状态，被动断开的一方，两次挥手完成之前，会进入CLOSE_WAIT状态。和双方是客户端还是服务端无关，因为TCP地位是对等的

time_wait一般是 单向通信的最大时间的2倍。为什么呢?

2倍的时间可以保证最后一个ACK尽可能的被对方收到，双方在断开连接的时候，网络中还有滞留的报文，这样可以保证滞留的报文进行消散。

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

服务端状态转化：

[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;

[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文.

[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.

[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;

[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)

[LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接

客户端状态转化:

[CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;

[SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;

[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入FIN_WAIT_1;

[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;

[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;

[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态.

下图是TCP状态转换的一个汇总:

较粗的虚线表示服务端的状态变化情况;

较粗的实线表示客户端的状态变化情况;

CLOSED是一个假想的起始点, 不是真实状态;

5.理解TIME_WAIT状态

现在做一个测试,首先启动server,然后启动client,然后用Ctrl-C使server终止,这时马上再运行server, 结果是绑定端口的时候就会绑定失败

这是因为,虽然server的应用程序终止了,但TCP协议层的连接并没有完全断开,因此不能再次监 听同样的server端口.

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的值;

cat /proc/sys/net/ipv4/tcp_fin_timeout

在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).

这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.

由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip, 源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题.

解决方法：我们可以使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符

setsockopt函数是用于设置套接字选项的函数。它允许我们在已经创建的套接字上设置一些特定的选项，以控制套接字的行为和属性。该函数的原型如下：

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);
参数说明：

sockfd：套接字描述符，指定要设置选项的套接字。
level：选项的级别，用于指定要设置的选项的协议层。常见的级别有SOL_SOCKET和IPPROTO_TCP等。
optname：选项名称，用于指定要设置的具体选项。例如，SO_REUSEADDR用于设置SOCKET重用地址选项。
optval：指向存储选项值的缓冲区的指针。
optlen：指定optval缓冲区的大小。
setsockopt函数常用的选项包括：

SO_REUSEADDR：允许地址重用，使得在套接字关闭后，该套接字所使用的地址可以立即被其他套接字使用。
SO_KEEPALIVE：启用连接保持活动状态，用于检测连接是否还存活。
SO_RCVBUF：设置接收缓冲区的大小。
SO_SNDBUF：设置发送缓冲区的大小。
TCP_NODELAY：禁用Nagle算法，用于减少数据包发送的延迟。
通过使用setsockopt函数，我们可以根据需要设置套接字的不同选项，以满足特定的需求和控制套接字的行为。

int opt = 1;
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));

6.理解CLOSE_WAIT状态

如果我们的服务器出现了大量的close_wait，有以下两种情况：

1.服务器有bug,没有做close文件描述符的动作

2.服务器有压力，可能一直在推送消息给client，导致来不及close

服务器进入了 CLOSE_WAIT 状态, 结合我们四次挥手的流程图, 可以认为四次挥手没有正确完成.

对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确

完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题

7.流量控制

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

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;

窗口大小字段越大, 说明网络的吞吐量越高;

接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;

发送端接受到这个窗口之后, 就会减慢自己的发送速度;

如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端

接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;

那么发送方怎么在第一次就知道对方的接收能力呢？因为在通信之前，就做过了三次握手，就可以交换窗口大小

那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?

实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位;

8.滑动窗口

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

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

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).

发送前四个段的时候, 不需要等待任何ACK, 直接发送;

收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;

操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;

窗口越大, 则网络的吞吐率就越高;

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

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

这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;

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

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

这种机制被称为 “高速重发控制”(也叫 “快重传”)

如何看待滑动窗口问题

建模1：

滑动窗口的大小是怎么设定的，对于目前来说，滑动窗口的大小和对方的接收能力有关

win_start = 0;
win_end = win_start + tcp_win
// 无论未来怎么移动，都要保证对方能够进行正常接收

滑动窗口大小 = 对方通告给我自己的接收能力的大小【目前】

1.滑动窗口一定会向右移动吗，会向左移动吗

可能会向右移动，也有可能不动，不可能向左移动。最左侧的报文应答之后会向右移动，但是如果一直不应答就不会移动

2.窗口会一直不变吗，会变大吗，会变小吗，变的依据是什么

win_start = ACK_SEQ;
win_end = win_start + tcp_win;

这取决于对方给我的ACK确认应答的序号以及对方窗口的大小，所以可能会变大，也有可能会变小

3.收到应答确认的时候，如果不是最左侧发送的报文确认，而是中间的，结尾的怎么办？

这时认为是丢包了，分为一下两种情况：

1.数据没丢，只是应答丢了。

2.数据真的丢了

我们知道确认序号的定义：ACK应答序号+1，表示这个序号前的所有的数据全部都接收到了

如果是应答丢了，那么后面的应答之后，也就说明前面的也收到了，所有前面的应答丢了没有影响

如果是数据丢了，那么确认序号就会重复，此时就知道是数据真的丢了，就会发生重传

4.滑动窗口必须要滑动吗，会不会不动了，或者变为0了

滑动窗口不是一定要移动，当上层不取走数据也没有新的应答此时窗口就不动了，当所有的报文都确认了应答，而上层没有把数据取走，此时窗口的大小为0

5.一直向右滑动，如果空间不够了怎么办

发送缓冲区被内核组织成了为环形结构，所以不会空间不够

所以，如果我们发送数据，没有收到应答之前，已经发送是户籍被暂时保存在滑动窗口中，支持超时重传

9.拥塞控制

如果客户端向服务端发送了10000个报文，如果有1-2个报文丢失了，那么客户端就会认为是自己的问题，就会选择重发，如果丢了9999个报文，那么客户端就会认为不是自己的问题了，此时是网络发生了问题，此时就不应该重传，不然又会出现大量的报文，只会加重网络的故障问题，所以就要进行拥塞控制。

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题. 因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的.

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

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

每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

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

为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.

此处引入一个叫做慢启动的阈值

当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

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

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

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

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

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

TCP拥塞控制这样的过程, 就好像 热恋的感觉

所以滑动窗口的大小 = min(拥塞窗口,窗口大小(自己的接收能力))

10.延迟应答

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

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

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

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

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

一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

那么所有的包都可以延迟应答么? 肯定也不是;

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

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

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

11.捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说

了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;

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

12.面向字节流

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

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

如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;

如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;

接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;

然后应用程序可以调用read从接收缓冲区拿数据;

另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

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

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

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

13.粘包问题

首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段. 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.站在应用层的角度, 看到的只是一串连续的字节数据.

那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

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

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

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

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

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

对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.

站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况

14.TCP异常情况

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

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

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

15.基于TCP应用层协议

HTTP

HTTPS

SSH

Telnet

FTP

SMTP

当然, 也包括你自己写TCP程序时自定义的应用层协议;

16.TCP小结

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

可靠性:

校验和

序列号(按序到达)

确认应答

超时重发

连接管理

流量控制

拥塞控制

提高性能:

滑动窗口

快速重传

延迟应答

捎带应答

其他:

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

17.TCP/UDP对比

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

TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;

UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播;

归根结底, TCP和UDP都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定

用UDP实现可靠传输(经典面试题)

参考TCP的可靠性机制, 在应用层实现类似的逻辑;

引入序列号, 保证数据顺序;

引入确认应答, 确保对端收到了数据;

引入超时重传, 如果隔一段时间没有应答, 就重发数据;

…

四、理解 listen 的第二个参数

我们先举一个例子，我们在海底捞吃火锅的时候，人满的时候服务员会告诉我们要先进行排队，那么什么需要排队呢，排队的本质就是让我们有资源空闲的时候，可以立马使用，提高资源(桌椅板凳)利用率。不能不排队也不能太长，不排队的话，在高峰期也会有桌子空闲出来，就不能很好的利用，太长了客户不能忍，而且为什么不把多出来的钱用来更改场地。

对于TCP协议，要为上层维护一个连接队列，这个队列不能没有也不能太长，这个队列我们称为全连接队列，这个队列的长度受listen第二个参数的影响。

这里我们进行测试，对于服务器, listen 的第二个参数设置为 2, 并且不调用 accept

此时启动 3 个客户端同时连接服务器, 用 netstat 查看服务器状态, 一切正常.

但是启动第四个客户端时, 发现服务器对于第四个连接的状态存在问题了

客户端状态正常, 但是服务器端出现了 SYN_RECV 状态, 而不是 ESTABLISHED 状态

这是因为, Linux内核协议栈为一个tcp连接管理使用两个队列:

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

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

而全连接队列的长度会受到 listen 第二个参数的影响.

全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了.

这个队列的长度通过上述实验可知, 是 listen 的第二个参数 + 1.

过了一段时间之后，那个处于SYN_RECV的连接就消失了(没有进行连接)