Linux网络socket套接字(完)(5)

文章目录

前言
一、多进程版的Tcp网络程序
- 捕捉SIGCHLD信号
- 让孙子进程提供服务
二、多线程版的Tcp网络程序
三、线程池版的Tcp网络程序
四、Tcp协议通讯流程
- 通讯流程总览
- 三次握手的过程
- 数据传输的过程
- 四次挥手的过程
总结

前言

结束喽，至少这个Tcp套接字有关内容要结束了~
还有点难过呢！

一、多进程版的Tcp网络程序

我们可以将当前的单执行流服务器改为多进程版的服务器。

当服务端调用accept函数获取到新连接后不是由当前执行流为该连接提供服务，而是当前执行流调用fork函数创建子进程，然后让子进程为父进程获取到的连接提供服务。

由于父子进程是两个不同的执行流，当父进程调用fork创建出子进程后，父进程就可以继续从监听套接字当中获取新连接，而不用关心获取上来的连接是否服务完毕。

子进程继承父进程的文件描述符表

需要注意的是，文件描述符表是隶属于一个进程的，子进程创建后会继承父进程的文件描述符表。比如父进程打开了一个文件，该文件对应的文件描述符是3，此时父进程创建的子进程的3号文件描述符也会指向这个打开的文件，而如果子进程再创建一个子进程，那么子进程创建的子进程的3号文件描述符也同样会指向这个打开的文件。

在这里插入图片描述
但当父进程创建子进程后，父子进程之间会保持独立性，此时父进程文件描述符表的变化不会影响子进程。最典型的代表就是匿名管道，父子进程在使用匿名管道进行通信时，父进程先调用pipe函数得到两个文件描述符，一个是管道读端的文件描述符，一个是管道写端的文件描述符，此时父进程创建出来的子进程就会继承这两个文件描述符，之后父子进程一个关闭管道的读端，另一个关闭管道的写端，这时父子进程文件描述符表的变化是不会相互影响的，此后父子进程就可以通过这个管道进行单向通信了。

对于套接字文件也是一样的，父进程创建的子进程也会继承父进程的套接字文件，此时子进程就能够对特定的套接字文件进行读写操作，进而完成对对应客户端的服务。

等待子进程问题

当父进程创建出子进程后，父进程是需要等待子进程退出的，否则子进程会变成僵尸进程，进而造成内存泄漏。因此服务端创建子进程后需要调用wait或waitpid函数对子进程进行等待。

阻塞式等待与非阻塞式等待：

如果服务端采用阻塞的方式等待子进程，那么服务端还是需要等待服务完当前客户端，才能继续获取下一个连接请求，此时服务端仍然是以一种串行的方式为客户端提供服务。
如果服务端采用非阻塞的方式等待子进程，虽然在子进程为客户端提供服务期间服务端可以继续获取新连接，但此时服务端就需要将所有子进程的PID保存下来，并且需要不断花费时间检测子进程是否退出。

总之，服务端要等待子进程退出，无论采用阻塞式等待还是非阻塞式等待，都不尽人意。此时我们可以考虑让服务端不等待子进程退出。

让父进程不等待子进程退出，常见的方式有两种：

捕捉SIGCHLD信号，将其处理动作设置为忽略。
让父进程创建子进程，子进程再创建孙子进程，最后让孙子进程为客户端提供服务。

捕捉SIGCHLD信号

实际当子进程退出时会给父进程发送SIGCHLD信号，如果父进程将SIGCHLD信号进行捕捉，并将该信号的处理动作设置为忽略，此时父进程就只需专心处理自己的工作，不必关心子进程了。

其实也是很好实现的，因此也是比较推荐的~

class TcpServer
{
public:void Start(){signal(SIGCHLD, SIG_IGN); //忽略SIGCHLD信号for (;;){//获取连接struct sockaddr_in peer;memset(&peer, '\0', sizeof(peer));socklen_t len = sizeof(peer);int sock = accept(_listen_sock, (struct sockaddr*)&peer, &len);if (sock < 0){std::cerr << "accept error, continue next" << std::endl;continue;}std::string client_ip = inet_ntoa(peer.sin_addr);int client_port = ntohs(peer.sin_port);std::cout << "get a new link->" << sock << " [" << client_ip << "]:" << client_port << std::endl;pid_t id = fork();if (id == 0){ //child//处理请求Service(sock, client_ip, client_port);exit(0); //子进程提供完服务退出}}}
private:int _listen_sock; 	//监听套接字int _port; 			//端口号
};

来段代码测试一下吧！

重新编译程序运行服务端后，可以通过以下监控脚本对服务进程进行监控。

while :; do ps axj | head -1 && ps axj | grep tcp_server | grep -v grep;echo "######################";sleep 1;done

此时可以看到，一开始没有客户端连接该服务器，此时服务进程只有一个，该服务进程就是不断获取新连接的进程，而获取到新连接后也是由该进程创建子进程为对应客户端提供服务的。

在这里插入图片描述
此时我们运行一个客户端，让该客户端连接服务器，此时服务进程就会调用 fork函数创建出一个子进程，由该子进程为这个客户端提供服务。

在这里插入图片描述
如果再有一个客户端连接服务器，此时服务进程会再创建出一个子进程，让该子进程为这个客户端提供服务。

在这里插入图片描述
最重要的是，由于这两个客户端分别由两个不同的执行流提供服务，因此这两个客户端可以同时享受到服务，它们发送给服务端的数据都能够在服务端输出，并且服务端也会对它们的数据进行响应。

在这里插入图片描述

当客户端一个个退出后，在服务端对应为之提供服务的子进程也会相继退出，但无论如何服务端都至少会有一个服务进程，这个服务进程的任务就是不断获取新连接。

在这里插入图片描述

让孙子进程提供服务

我们也可以让服务端创建出来的子进程再次进行fork，让孙子进程为客户端提供服务，此时我们就不用等待孙子进程退出了。

命名说明：

爷爷进程：在服务端调用accept函数获取客户端连接请求的进程。
爸爸进程：由爷爷进程调用fork函数创建出来的进程。
孙子进程：由爸爸进程调用fork函数创建出来的进程，该进程调用Service函数为客户端提供服务。

我们让爸爸进程创建完孙子进程后立刻退出，此时服务进程（爷爷进程）调用wait/waitpid函数等待爸爸进程就能立刻等待成功，此后服务进程就能继续调用accept函数获取其他客户端的连接请求。

不需要等待孙子进程退出

而由于爸爸进程创建完孙子进程后就立刻退出了，因此实际为客户端提供服务的孙子进程就变成了孤儿进程，该进程就会被系统领养，当孙子进程为客户端提供完服务退出后系统会回收孙子进程，所以服务进程（爷爷进程）是不需要等待孙子进程退出的。

关闭对应的文件描述符

服务进程（爷爷进程）调用accept函数获取到新连接后，会让孙子进程为该连接提供服务，此时服务进程已经将文件描述符表继承给了爸爸进程，而爸爸进程又会调用 fork函数创建出孙子进程，然后再将文件描述符表继承给孙子进程。

而父子进程创建后，它们各自的文件描述符表是独立的，不会相互影响。因此服务进程在调用fork函数后，服务进程就不需要再关心刚才从accept函数获取到的文件描述符了，此时服务进程就可以调用close函数将该文件描述符进行关闭。

同样的，对于爸爸进程和孙子进程来说，它们是不需要关心从服务进程（爷爷进程）继承下来的监听套接字的，因此爸爸进程可以将监听套接字关掉。

关闭文件描述符的必要性：

对于服务进程来说，当它调用fork函数后就必须将从accept函数获取的文件描述符关掉。因为服务进程会不断调用accept函数获取新的文件描述符（服务套接字），如果服务进程不及时关掉不用的文件描述符，最终服务进程中可用的文件描述符就会越来越少。
而对于爸爸进程和孙子进程来说，还是建议关闭从服务进程继承下来的监听套接字。实际就算它们不关闭监听套接字，最终也只会导致这一个文件描述符泄漏，但一般还是建议关上。因为孙子进程在提供服务时可能会对监听套接字进行某种误操作，此时就会对监听套接字当中的数据造成影响。

class TcpServer
{
public:void Start(){for (;;){//获取连接struct sockaddr_in peer;memset(&peer, '\0', sizeof(peer));socklen_t len = sizeof(peer);int sock = accept(_listen_sock, (struct sockaddr*)&peer, &len);if (sock < 0){std::cerr << "accept error, continue next" << std::endl;continue;}std::string client_ip = inet_ntoa(peer.sin_addr);int client_port = ntohs(peer.sin_port);std::cout << "get a new link->" << sock << " [" << client_ip << "]:" << client_port << std::endl;pid_t id = fork();if (id == 0){ //childclose(_listen_sock); //child关闭监听套接字if (fork() > 0){exit(0); //爸爸进程直接退出}//处理请求Service(sock, client_ip, client_port); //孙子进程提供服务exit(0); //孙子进程提供完服务退出}close(sock); //father关闭为连接提供服务的套接字waitpid(id, nullptr, 0); //等待爸爸进程（会立刻等待成功）}}
private:int _listen_sock; //监听套接字int _port; //端口号
};

至于测试就交给大家啦！

二、多线程版的Tcp网络程序

创建进程的成本是很高的，创建进程时需要创建该进程对应的进程控制块（task_struct）、进程地址空间（mm_struct）、页表等数据结构。而创建线程的成本比创建进程的成本会小得多，因为线程本质是在进程地址空间内运行，创建出来的线程会共享该进程的大部分资源，因此在实现多执行流的服务器时最好采用多线程进行实现。

当服务进程调用accept函数获取到一个新连接后，就可以直接创建一个线程，让该线程为对应客户端提供服务。

当然，主线程（服务进程）创建出新线程后，也是需要等待新线程退出的，否则也会造成类似于僵尸进程这样的问题。但对于线程来说，如果不想让主线程等待新线程退出，可以让创建出来的新线程调用pthread_detach函数进行线程分离，当这个线程退出时系统会自动回收该线程所对应的资源。此时主线程（服务进程）就可以继续调用accept函数获取新连接，而让新线程去服务对应的客户端。

各个线程共享同一张文件描述符表

文件描述符表维护的是进程与文件之间的对应关系，因此一个进程对应一张文件描述符表。而主线程创建出来的新线程依旧属于这个进程，因此创建线程时并不会为该线程创建独立的文件描述符表，所有的线程看到的都是同一张文件描述符表。

在这里插入图片描述
因此当服务进程（主线程）调用accept函数获取到一个文件描述符后，其他创建的新线程是能够直接访问这个文件描述符的。

需要注意的是，虽然新线程能够直接访问主线程accept上来的文件描述符，但此时新线程并不知道它所服务的客户端对应的是哪一个文件描述符，因此主线程创建新线程后需要告诉新线程对应应该访问的文件描述符的值，也就是告诉每个新线程在服务客户端时，应该对哪一个套接字进行操作。

参数结构体

实际新线程在为客户端提供服务时就是调用 Service函数，而调用 Service函数时是需要传入三个参数的，分别是客户端对应的套接字、IP地址和端口号。因此主线程创建新线程时需要给新线程传入三个参数，而实际在调用 pthread_create函数创建新线程时，只能传入一个类型为 void * 的参数。

这时我们可以设计一个参数结构体Param，此时这三个参数就可以放到Param结构体当中，当主线程创建新线程时就可以定义一个Param对象，将客户端对应的套接字、IP地址和端口号设计进这个Param对象当中，然后将Param对象的地址作为新线程执行例程的参数进行传入。

此时新线程在执行例程当中再将这个void类型的参数强转为Param类型，然后就能够拿到客户端对应的套接字，IP地址和端口号，进而调用Service函数为对应客户端提供服务。

class Param
{
public:Param(int sock, std::string ip, int port): _sock(sock), _ip(ip), _port(port){}~Param(){}
public:int _sock;std::string _ip;int _port;
};

文件描述符关闭的问题

由于此时所有线程看到的都是同一张文件描述符表，因此当某个线程要对这张文件描述符表做某种操作时，不仅要考虑当前线程，还要考虑其他线程。
对于主线程accept上来的文件描述符，主线程不能对其进行关闭操作，该文件描述符的关闭操作应该又新线程来执行。因为是新线程为客户端提供服务的，只有当新线程为客户端提供的服务结束后才能将该文件描述符关闭。
对于监听套接字，虽然创建出来的新线程不必关心监听套接字，但新线程不能将监听套接字对应的文件描述符关闭，否则主线程就无法从监听套接字当中获取新连接了。

Service函数定义为静态成员函数

由于调用 pthread_create函数创建线程时，新线程的执行例程是一个参数为void* ，返回值为void* 的函数。如果我们要将这个执行例程定义到类内，就需要将其定义为静态成员函数，否则这个执行例程的第一个参数是隐藏的this指针。

在线程的执行例程当中会调用 Service函数，由于执行例程是静态成员函数，静态成员函数无法调用非静态成员函数，因此我们需要将 Service函数定义为静态成员函数。恰好 Service函数内部进行的操作都是与类无关的，因此我们直接在Service函数前面加上一个static即可。

class TcpServer
{
public:static void* HandlerRequest(void* arg){pthread_detach(pthread_self()); //分离线程//int sock = *(int*)arg;Param* p = (Param*)arg;Service(p->_sock, p->_ip, p->_port); //线程为客户端提供服务delete p; //释放参数占用的堆空间return nullptr;}void Start(){for (;;){//获取连接struct sockaddr_in peer;memset(&peer, '\0', sizeof(peer));socklen_t len = sizeof(peer);int sock = accept(_listen_sock, (struct sockaddr*)&peer, &len);if (sock < 0){std::cerr << "accept error, continue next" << std::endl;continue;}std::string client_ip = inet_ntoa(peer.sin_addr);int client_port = ntohs(peer.sin_port);std::cout << "get a new link->" << sock << " [" << client_ip << "]:" << client_port << std::endl;Param* p = new Param(sock, client_ip, client_port);pthread_t tid;pthread_create(&tid, nullptr, HandlerRequest, p);}}
private:int _listen_sock; //监听套接字int _port; //端口号
};

代码测试

此时我们再重新编译服务端代码，由于代码当中用到了多线程，因此编译时需要携带上-pthread 选项。此外，由于我们现在要监测的是一个个的线程，因此在监控时使用的不再是 ps -axj 命令，而是 ps -aL命令

while :; do ps -aL | head -1 & &ps -aL | grep tcp_server;echo "####################";sleep 1;done

运行服务端，通过监控可以看到，此时只有一个服务线程，该服务线程就是主线程，它现在在等待客户端的连接到来。
在这里插入图片描述
当一个客户端连接到服务端后，此时主线程就会为该客户端构建一个参数结构体，然后创建一个新线程，将该参数结构体的地址作为参数传递给这个新线程，此时该新线程就能够从这个参数结构体当中提取出对应的参数，然后调用Service函数为该客户端提供服务，因此在监控当中显示了两个线程。

在这里插入图片描述
再来一个客户端！

在这里插入图片描述
由于为这两个客户端提供服务的也是两个不同的执行流，因此这两个客户端可以同时享受服务端提供的服务，它们发送给服务端的消息也都能够在服务端进行打印，并且这两个客户端也都能够收到服务端的回显数据。

在这里插入图片描述
此时无论有多少个客户端发来连接请求，在服务端都会创建出相应数量的新线程为对应客户端提供服务，而当客户端一个个退出后，为其提供服务的新线程也就会相继退出，最终就只剩下最初的主线程仍在等待新连接的到来。

在这里插入图片描述

三、线程池版的Tcp网络程序

先来看下多线程版本的服务器存在哪些问题：

每当有新连接到来时，服务端的主线程都会重新为该客户端创建为其提供服务的新线程，而当服务结束后又会将该新线程销毁。这样做不仅麻烦，而且效率低下，每当连接到来的时候服务端才创建对应提供服务的线程。
如果有大量的客户端连接请求，此时服务端要为每一个客户端创建对应的服务线程。计算机当中的线程越多，CPU的压力就越大，因为CPU要不断在这些线程之间来回切换，此时CPU在调度线程的时候，线程和线程之间切换的成本就会变得很高。此外，一旦线程太多，每一个线程再次被调度的周期就变长了，而线程是为客户端提供服务的，线程被调度的周期变长，客户端也迟迟得不到应答。

针对这两个问题，对应的解决思路如下：

可以在服务端预先创建一批线程，当有客户端请求连接时就让这些线程为客户端提供服务，此时客户端一来就有线程为其提供服务，而不是当客户端来了才创建对应的服务线程。
当某个线程为客户端提供完服务后，不要让该线程退出，而是让该线程继续为下一个客户端提供服务，如果当前没有客户端连接请求，则可以让该线程先进入休眠状态，当有客户端连接到来时再将该线程唤醒。
服务端创建的这一批线程的数量不能太多，此时CPU的压力也就不会太大。此外，如果有客户端连接到来，但此时这一批线程都在给其他客户端提供服务，这时服务端不应该再创建线程，而应该让这个新来的连接请求在全连接队列进行排队，等服务端这一批线程中有空闲线程后，再将该连接请求获取上来并为其提供服务。

其实就是引入线程池

先来回顾一下线程池的代码：

#define NUM 5//线程池
template<class T>
class ThreadPool
{
private:bool IsEmpty(){return _task_queue.size() == 0;}void LockQueue(){pthread_mutex_lock(&_mutex);}void UnLockQueue(){pthread_mutex_unlock(&_mutex);}void Wait(){pthread_cond_wait(&_cond, &_mutex);}void WakeUp(){pthread_cond_signal(&_cond);}
public:ThreadPool(int num = NUM): _thread_num(num){pthread_mutex_init(&_mutex, nullptr);pthread_cond_init(&_cond, nullptr);}~ThreadPool(){pthread_mutex_destroy(&_mutex);pthread_cond_destroy(&_cond);}//线程池中线程的执行例程static void* Routine(void* arg){pthread_detach(pthread_self());ThreadPool* self = (ThreadPool*)arg;//不断从任务队列获取任务进行处理while (true){self->LockQueue();while (self->IsEmpty()){self->Wait();}T task;self->Pop(task);self->UnLockQueue();task.Run(); //处理任务}}void ThreadPoolInit(){pthread_t tid;for (int i = 0; i < _thread_num; i++){pthread_create(&tid, nullptr, Routine, this); //注意参数传入this指针}}//往任务队列塞任务（主线程调用）void Push(const T& task){LockQueue();_task_queue.push(task);UnLockQueue();WakeUp();}//从任务队列获取任务（线程池中的线程调用）void Pop(T& task){task = _task_queue.front();_task_queue.pop();}private:std::queue<T> _task_queue; //任务队列int _thread_num; //线程池中线程的数量pthread_mutex_t _mutex;pthread_cond_t _cond;
};

服务类新增线程池成员

现在服务端引入了线程池，因此在服务类当中需要新增一个指向线程池的指针成员：

当实例化服务器对象时，先将这个线程池指针先初始化为空。
当服务器初始化完毕后，再实际构造这个线程池对象，在构造线程池对象时可以指定线程池当中线程的个数，也可以不指定，此时默认线程的个数为5。
在启动服务器之前对线程池进行初始化，此时就会将线程池当中的若干线程创建出来，而这些线程创建出来后就会不断检测任务队列，从任务队列当中拿出任务进行处理。
现在当服务进程调用accept函数获取到一个连接请求后，就会根据该客户端的套接字、IP地址以及端口号构建出一个任务，然后调用线程池提供的Push接口将该任务塞入任务队列。

这实际也是一个生产者消费者模型，其中服务进程就作为了任务的生产者，而后端线程池当中的若干线程就不断从任务队列当中获取任务进行处理，它们承担的就是消费者的角色，其中生产者和消费者的交易场所就是线程池当中的任务队列。

class TcpServer
{
public:TcpServer(int port): _listen_sock(-1), _port(port), _tp(nullptr){}void InitServer(){//创建套接字_listen_sock = socket(AF_INET, SOCK_STREAM, 0);if (_listen_sock < 0){std::cerr << "socket error" << std::endl;exit(2);}//绑定struct sockaddr_in local;memset(&local, '\0', sizeof(local));local.sin_family = AF_INET;local.sin_port = htons(_port);local.sin_addr.s_addr = INADDR_ANY;if (bind(_listen_sock, (struct sockaddr*)&local, sizeof(local)) < 0){std::cerr << "bind error" << std::endl;exit(3);}//监听if (listen(_listen_sock, BACKLOG) < 0){std::cerr << "listen error" << std::endl;exit(4);}_tp = new ThreadPool<Task>(); //构造线程池对象}void Start(){_tp->ThreadPoolInit(); //初始化线程池for (;;){//获取连接struct sockaddr_in peer;memset(&peer, '\0', sizeof(peer));socklen_t len = sizeof(peer);int sock = accept(_listen_sock, (struct sockaddr*)&peer, &len);if (sock < 0){std::cerr << "accept error, continue next" << std::endl;continue;}std::string client_ip = inet_ntoa(peer.sin_addr);int client_port = ntohs(peer.sin_port);std::cout << "get a new link->" << sock << " [" << client_ip << "]:" << client_port << std::endl;Task task(sock, client_ip, client_port); //构造任务_tp->Push(task); //将任务Push进任务队列}}
private:int _listen_sock; 		//监听套接字int _port; 				//端口号ThreadPool<Task>* _tp; 	//线程池
};

现在来设计任务类吧！

现在我们要做的就是设计一个任务类，该任务类当中需要包含客户端对应的套接字、IP地址、端口号，表示该任务是为哪一个客户端提供服务，对应操作的套接字是哪一个。

此外，任务类当中需要包含一个Run方法，当线程池中的线程拿到任务后就会直接调用这个Run方法对该任务进行处理，而实际处理这个任务的方法就是服务类当中的Service函数，服务端就是通过调用Service函数为客户端提供服务的。

我们可以直接拿出服务类当中的Service函数，将其放到任务类当中作为任务类当中的Run方法，但这实际不利于软件分层。我们可以给任务类新增一个仿函数成员，当执行任务类当中的Run方法处理任务时就可以以回调的方式处理该任务。

class Task
{
public:Task(){}Task(int sock, std::string client_ip, int client_port): _sock(sock), _client_ip(client_ip), _client_port(client_port){}~Task(){}//任务处理函数void Run(){_handler(_sock, _client_ip, _client_port); //调用仿函数}
private:int _sock; 				//套接字std::string _client_ip; //IP地址int _client_port; 		//端口号Handler _handler; 		//处理方法
};

注意：当任务队列当中有任务时，线程池当中的线程会先定义出一个Task对象，然后将这个Task对象作为输出型参数调用任务队列的Pop函数，从任务队列当中获取任务，因此Task类除了提供带参的构造函数以外，还需要提供一个无参的构造函数，方便我们可以定义无参对象。

设计Handler类

此时需要再设计一个Handler类，在Handler类当中对()操作符进行重载，将()操作符的执行动作重载为执行Service函数的代码。

class Handler
{
public:Handler(){}~Handler(){}void operator()(int sock, std::string client_ip, int client_port){char buffer[1024];while (true){ssize_t size = read(sock, buffer, sizeof(buffer) - 1);if (size > 0){ //读取成功buffer[size] = '\0';std::cout << client_ip << ":" << client_port << "# " << buffer << std::endl;write(sock, buffer, size);}else if (size == 0){ //对端关闭连接std::cout << client_ip << ":" << client_port << " close!" << std::endl;break;}else{ //读取失败std::cerr << sock << " read error!" << std::endl;break;}}close(sock); //归还文件描述符std::cout << client_ip << ":" << client_port << " service done!" << std::endl;}
};

实际我们可以让服务器处理不同的任务，当前服务器只是在进行字符串的回显处理，而实际要怎么处理这个任务完全是由任务类当中的 handler成员来决定的。

如果想要让服务器处理其他任务，只需要修改 Handler类当中对()的重载函数就行了，而服务器的初始化、启动服务器以及线程池的代码都是不需要更改的，这就叫做把通信功能和业务逻辑在软件上做解耦。

测试代码

现在我们将代码重新编译并运行，运行一下bash代码来查看服务端的各个线程

while :; do ps -aL|head -1&&ps -aL|grep tcp_server;echo "####################";sleep 1;done

运行服务端后，就算没有客户端发来连接请求，此时在服务端就已经有了6个线程，其中有一个是接收新连接的服务线程，而其余的5个是线程池当中为客户端提供服务的线程。

在这里插入图片描述

当然，无论现在有多少客户端发来请求，在服务端都只会有线程池当中的5个线程为之提供服务，线程池当中的线程个数不会随着客户端连接的增多而增多，这些线程也不会因为客户端的退出而退出。

四、Tcp协议通讯流程

最后的最后，让我们再次回顾一下Tcp的协议通讯流程吧，并且我会为大家再次讲解一下原理！

通讯流程总览

下图是基于Tcp协议的客户端/服务器程序的一般流程：

在这里插入图片描述
下面我们结合Tcp协议的通信流程，来初步认识一下三次握手和四次挥手，以及建立连接和断开连接与各个网络接口之间的对应关系。

三次握手的过程

在这里插入图片描述

初始化服务器

当服务器完成套接字创建、绑定以及监听的初始化动作之后，就可以调用accept函数阻塞等待客户端发起请求连接了。

服务器初始化：

调用socket，创建文件描述符。
调用bind，将当前的文件描述符和IP/PORT绑定在一起，如果这个端口已经被其他进程占用了，就会bind失败。
调用listen，声明当前这个文件描述符作为一个服务器的文件描述符，为后面的accept做好准备。
调用accept，并阻塞，等待客户端连接到来。

建立连接

而客户端在完成套接字创建后，就会在合适的时候通过connect函数向服务器发起连接请求，而客户端在connect的时候本质是通过某种方式向服务器三次握手，因此connect的作用实际就是触发三次握手。

建立连接的过程：

调用socket，创建文件描述符。
调用connect，向服务器发起连接请求。
connect会发出SYN段并阻塞等待服务器应答（第一次）。
服务器收到客户端的SYN，会应答一个SYN-ACK段表示“同意建立连接”（第二次）。
客户端收到SYN-ACK后会从connect返回，同时应答一个ACK段（第三次）。

这个建立连接的过程，通常称为三次握手。

需要注意的是，连接并不是立马建立成功的，由于TCP属于传输层协议，因此在建立连接时双方的操作系统会自主进行三次协商，最后连接才会建立成功。

数据传输的过程

在这里插入图片描述

数据交互

连接一旦建立成功并且被accept获取上来后，此时客户端和服务器就可以进行数据交互了。需要注意的是，连接建立和连接被拿到用户层是两码事，accept函数实际不参与三次握手这个过程，因为三次握手本身就是底层TCP所做的工作。accept要做的只是将底层已经建立好的连接拿到用户层，如果底层没有建立好的连接，那么accept函数就会阻塞住直到有建立好的连接。

而双方在进行数据交互时使用的实际就是read和write，其中write就叫做写数据，read就叫做读数据。write的任务就是把用户数据拷贝到操作系统，而拷贝过去的数据何时发以及发多少，就是由TCP决定的。而read的任务就是把数据从内核读到用户。

数据传输的过程：

建立连接后，TCP协议提供全双工的通信服务，所谓全双工的意思是，在同一条连接中，同一时刻，通信双方可以同时写数据，相对的概念叫做半双工，同一条连接在同一时刻，只能由一方来写数据。
服务器从accept返回后立刻调用read，读socket就像读管道一样，如果没有数据到达就阻塞等待。
这时客户端调用write发送请求给服务器，服务器收到后从read返回，对客户端的请求进行处理，在此期间客户端调用read阻塞等待服务器端应答。
服务器调用write将处理的结果发回给客户端，再次调用read阻塞等待下一条请求。
客户端收到后从read返回，发送下一条请求，如此循环下去。