首先我们先说下网络编程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
在通过一个客户端建立连接后，可以看到建立了一条连接，服务器端的端口号是8000，监听的还是8000。
在连接一个客户端，可以看到建立了两条连接，服务器端都是使用8000，监听的还是8000。
