从源码角度配合网络编程函数accept() connect()等实现的客户端服务器通信分析下三握手四挥手都做了什么

news2024/11/15 7:47:14

首先我们先说下网络编程API：

数据在网络上通信，通信的双方一个是客户端，一个是服务器

更具体来说，不是客户端和服务器这两个机器在经由互联网进行通信，

而是客户端上的某一进程与服务器端的某一进程进行通信。

因此，客户端与服务器间的通信是一个进程间通信，只不过通信的两个进程不在同一机器上。

所以进程间通信方式实际上有 ①管道（命名管道、无名管道）；②消息队列；③共享内存；④信号量；⑤信号；⑥套接字Socket 这6种方式

其中的套接字Socket 通信就是指不在同一机器上，需要经由网络进行通信的进程间通信方式

【具体详见： XXXXX插入一条链接】--》链接内容就是socket 作为内河中的缓冲区，是如何被fd指向来接受梁金成穿来穿去的数据的

现在，客户端进程与服务器进程要通信，如何使用Socket套接字呢，需要以下流程：

不加任何IO复用技术的客户端与服务器之间数据的交换调用函数如下：

使用epoll来监听的socket通信流程调用API如下：（图中只画了三次握手和传输数据，没画关闭连接阶段，，，）

但，无论是哪种方式（无论是程序员自己写逻辑轮询监听文件描述符还是使用select\poll\epoll），客户端与服务器间建立连接【发生三次握手】的位置都是：connect()函数与 accept()函数交互的位置，如下图所示：

首先，让我们了解下三次握手四次挥手过程的状态转换：

连接建立阶段：

第一次握手：客户端的应用进程向服务器端发出连接请求报文：发送连接请求后，客户端状态变为 "SYN_SENT"

请求报文内容为：其首部中：SYN值置为1 ；seq=x

第二次握手：服务器应用进程响应客户端的连接请求，向客户端发回确认报文和连接请求：而后，服务器端的状态变为 "SYN_RECV"

请求报文内容为：其首部中：SYN值置为1，ACK值置为1 ；ack=x+1，seq=y。

第三次握手：客户端收到确认报文之后，通知上层应用进程连接已建立，并向服务器发出确认报文：而后，客户端状态变为 "ESTABLISHED"

请求报文内容为：其首部中：ACK值置为1，ack=y+1

(服务器端收到第三次握手客户端发来的确认报文，状态也变为 "ESTABLISHED")

至此，TCP连接就建立了，客户端和服务器可以愉快地玩耍了。只要通信双方没有一方发出连接释放的请求，连接就将一直保持。

连接释放阶段：（假设客户端主动关闭连接）

第一次挥手：客户端发送一个断开连接包（FIN包）：而后，客户端状态变为 "FIN_WAIT_1"

请求报文内容为：其首部中：FIN值置为1，ACK值置为1 ；ack=... ，seq=... 。

(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)

第二次挥手：服务器端收到FIN包后，发送一个确认包给对方：而后，服务器端的状态变为 "CLOSE_WAIT"

请求报文内容为：其首部中：ACK值置为1 ；ack=... 。

第三次挥手：服务器端发送一个FIN包，告诉客户端我的数据也发送完了，不会再给你发数据了：而后，服务器端的状态变为 "LAST_ACK"

请求报文内容为：其首部中：FIN 值置为1，ACK值置为1 ；ack=...

第四次挥手：客户端接收到服务器端发来的FIN包，发送一个ACK给服务器端，状态转换为："TIME_WAIT"

服务器端接收到客户端发来的ACK包，断开与客户端的连接

客户端处于 “TIME_WAIT”状态 2MSL 时间后，也断开连接，进入"CLOSE"状态

至此，完成四次挥手

三次握手发生在 connect()函数和 accept() 函数中，这俩函数具体干了些什么？

服务器端接收到 connect()函数实现的对服务器端的连接请求后，accept()函数与之交互：

connect()函数调用时：

由于服务器端的ip和port都已经作为地址参数传入给connect()，

因此，第一次握手时，connect()函数去封装好一个SYN包，并且在该SYN包中也写明了 seq内容、window 大小等一系列后续数据传输的参数信息，并将自己的状态置为 SYN_SEND；

第二次握手时，服务器端接收到请求：会新建一个socket （为方便称呼我们称之为 new_socket），并将客户端的ip和端口号写入该新建的socket中，而后，返回连接请求SYN包和ACK；

第三次握手：客户端接收到应答：判断自己socket()此时状态是“SYN_SEND”，而后接受服务器端返回的ACK包，解析出ACK应答包中的通信socket的具体内容，例如window大小等，并把服务器端的ip和port写入到自己的socket中，为以后的信息传递做准备

## 一个疑问：服务器端调用accept()生成新的new_socket与客户端通信，那么，客户端访问服务器端时，它的端口号还会是客户端用于监听的socket的80端口吗？

答案是：是的，客户端在后续的数据传输中还是在访问 80端口。因为 accept 函数新创建的socket对象其实并没有进行端口的占有，而是复制了socetfd的本地IP和端口号，并且也向其中记录了连接过来的客户端的IP和端口号

## 那，多个客户端建立了多个连接请求，都在访问80端口，服务器端怎么知道那个请求时对应哪个客户端呢？

答案是：这是因为，socket不仅是一个进程间通信缓冲区，它还包含了一个用于记录控制信息的结构体，其中记录了这块缓冲区用于承担源和目的2个进程其进程ip和端口号

因此，客户端A访问ip和80端口，服务器端对80端口的监听程序（如epoll）就会发现有数据到来，接着就会判断，这个分析这个数据包内容：

若是一个未完成三次握手连接的新客户端在发送SYN包请求连接，则，调用accept() 来新建new_socket()与之进行三次握手操作

若是一个已完成三次握手连接的客户端发送来的数据，那么就根据该数据包则将数据放入接收缓冲区（TCP/IP协议栈维护一个接收发送数据的缓冲区），当该数据包的接受进程KK需要读数据的时候，通过调用了recv() 或read() ，进程KK根据其socket中记录的源目的ip和端口，从缓冲区中轻易找到该数据包，（并读到自己的socket空间中【这块不确定，要不别说了】）

这就是为啥服务器端即使就用一个端口也 不会弄混 不同客户端发来的请求和处理的消息。

如下图所示：

服务器监听8000端口，在未建立连接时，可以看到在监听8000