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报文