TCP网络编程中connect() 、listen() 和accept()三者之间关系

TCP网络编程开发分为服务器端和客户端两个部分 

对于服务器端开发主要流程--类似于 接电话过程

socket()[找到一个可以通话的手机]----->bind()[插入一个固定号码]------>listen()-------> accept------->recv()------->send()------>close();

对于客户端开发主要流程----类似于打电话过程

socket()----->connect()------>recv/read/send------>close()

对于TCP协议 =建立连接就在客户端connect（）与服务器listen之间 建立TCP连接（三次握手） 

对于四次挥手 状态两个PC之间close状态

1.  Connect（）函数：是一个阻塞函数 通过TCp三次握手父服务器建立连接

客户端主动连接服务器 建立连接方式通过TCP三次握手 通知Linux内核自动完成TCP 三次握手连接 如果连接成功为0 失败返回值-1

一般的情况下 客户端的connect函数 默认是阻塞行为 直到三次握手阶段成功为止。

2.服务器端的listen() 函数：不是一个阻塞函数： 功能：将套接字 和 套接字对应队列的长度告诉Linux内核

  他是被动连接的 一直监听来自不同客户端的请求 listen函数只要 作用将socketfd 变成被动的连接监听socket 其中参数backlog作用 设置内核中队列的长度 。

3.accept() 函数 阻塞： 从处于established 状态的队列中取出完成的连接 当队列中没有完成连接时候 会形成阻塞，直到取出队列中已完成连接的用户连接为止。

  问题一：服务器没有及时调用accept函数取走完成连接的队列怎么办？

服务器的连接队列满掉后，服务器不会对再对建立新连接的syn进行应答，所以客户端的 connect 就会返回 ETIMEDOUT。但实际上Linux的并不是这样的 当TCP连接队列满了之后 Linux并不会书中所说的拒绝连接，只是会延时连接。

2.TCP三次握手机制：三次握手机制保证通信是双工，可靠保证 更多通过重传机制

1.Client 主动向处于listen状态的服务器发送 SYN_SENT 报文；

2. Server SYN_RECVD之后 分配资源内存同时向client发送 SYN_ACK 确认接受的报文

3.Client 接受到服务器SYN_ACK 本地开辟内存资源 同时回复Server 发送SYN_ACK+I报文已经接受ACK报文信息 至此TCP连接建立起来

3.TCP 四次挥手：

  1.客户端A向服务器发送FIN，用来用来关闭A到serverB的数据传送

  2.服务器B接受到 这个FIN 它发回一个ACK确认报文 确认序列号+1 （客户端处于FIN_WAIT2）

  3.服务器B关闭客户端A的连接发送一个FIN报文 自己进行连接关闭

  4.客户端A 接受到server的FIN报文 回复ACK报文确认 此时客户端进入TIME_WAT d等待 经过2MLS 没有收到服务器的ACK确认信息自动进行关闭。

FIN报文 告诉自己 对方没有数据进行发送 并不能阻止自己发送数据，因此有可能还是有些数据发生给对方因此在关闭连接时候 ACK报文与FIN报文是分开 这也导致关闭时候需要四次挥手

问题一：TIME_WAT 状态中还需要等待2MS时间后才进行关闭

  虽然双方都同意关闭连接 按理可以直接回到 CLOSED 状态，事实上网络不可靠的 无法保证服务器能够接受到客户端的ACK确认消息。有可能让处于last_ACK 的server 认为超时重复FIN报文，所以TIME_WAT状态 作用重发可能丢失的ACK报文