4.3Posix API与网络协议栈

tcp server。Linux下服务端api:1.socket  2.bind   3. listen    4.accept    5.recv    6.send    7.close

tcp client  客户端:1.socket    2.bind(optional)   3.connect()    4.send    5.recv   6.close()

1. socket:插   座两部分。一部分是fd（文件描述符），tcb(tcp control block)。fd是我们操作的，tcbs是底层协议栈里面的。两者对应。fd是文件系统里面的，tcb是与tcp连接一对一的，所谓的tcp连接就是指对应的tcb

首先创建socket的时候fd=3。即任何一个进程的fd是从3开始的。因为0、1、2分别为标准输入输出，stderr,setin,stdout。

当socket创建fd和tcb的时候，tcb处于closed状态。此时即无法接收，也无法发送数据。当bind函数绑定好ip和port的时候，就可以接收数据了（知道由哪个tcb接收）

bind()函数，在接收或者发送数据的时候，用来填充本机的ip与端口。把对应的ip地址，端口，绑定在tcb里面

socket和bind是本地操作，与对端无关。

5元组（remoteip,remoteport,localip,locaoport,proto协议类型）

三次握手发生在协议栈中，由协议栈与协议栈之间完成，与api无关。

三次握手：客户端（协议栈内部）发送第一次连接（发送同步头syn seqnum=），即由客户端发送一个数据包到服务端（这个数据包是看不到的，不是通过send发送的），服务端接收到后，返回信息表示（发送同步头，同样由协议栈完成，我们看不到）确认收到请求信息，此时有了双向这个概念。客户端再次发送一次。

三次握手为什么是三次：没有确定答案。因为确定双向通信。

三次握手时服务端收到客户端的数据包后，解析出五元组，从而构建出一个tcb节点。此时连接便开始有了生命周期，但此时这个连接还不能用，还没有分配socket，此时会把这个tcb加入半连接队列（半连接队列，也叫syn队列）半连接队列中所有tcb是处于SYN RECV状态。当服务端收到第三次握手的时候，先通过五元组在半连接队列中查找，查到后将此tcb放入全连接队列，此时tcb状态变为is finished。此时服务端调用accept()函数，acccept函数做两件事：从全连接队列中取出一个节点，然后为这个节点分配一个fd返回。这个fd与这个节点的tcb一一对应。

若服务器收不到第三次握手，有个超时操作，服务器再次发送一个消息，若超时便丢弃这个半连接。

连接队列简历的前提是服务端进入listen状态。

客户端调用connect的时候，此函数执行成功后，协议栈发送一个同步头。connect阻塞到接收到服务端发送过来的数据包。

listen(listenfd,backlog)第二个参数的含义：半连接队列和全连接队列中tcb总数，未分配fd的总数不能超过backlog，或者理解为全连接队列的长度。

服务器端口只有65535.如何做到100w连接呢？端口复用。100w连接是指100w个fd，即100w个tcb，每个tcb通过五元组确定的。

每个连接对应一个tcb。这个tcb通过五元组确定。只要五元组够多，就可以建立很多连接。

数据发送：

send作用：把app中的数据copy到tcb中的sendbuffer（在内核协议栈中）中。send只是一个copy的过程。什么时机发送不由我们决定。即send与发送数据是异步的。因此有时send返回值为正数，却发送失败。

数据接收：用户接收数据和协议栈接收数据同样是两个过程，接收的数据先放在协议栈中recvbuffer中，recv从recvbuffer中copy到用户空间。

connect函数阻不阻塞取决于对应的fd是不是阻塞的，fd是不是阻塞由socket创建时我们决定。connect连接成功后返回0，此时对应的fd处于可写状态。

粘包，分包。ack

调用三次send，就会从用户空间往协议栈拷贝3此（send一次，拷贝一次），实际协议栈如何发送，发送几次，不由我们控制。如果协议栈发送了两次，此时对端接收的时候，recv便会接收两次，（此时便涉及黏包分报恩问题），数据包会合在一起。有两种方式：1、发送的时候在协议头上写明这个包有多长，2、为每个包加个分隔符。

tcp如何保证包的发送顺序呢？延迟ack保证顺序。接收端有个定时器（延迟ack），接收到一个包重置一次。若超时没收到会回发一个ack数据。比如发送5个包，接收到了包1，2，3，5。接收端会回发ack=4表示4及以后的需要重发。缺少的包及其后面部分需要重发。这层延迟ack是tcp协议栈做的事（这个超时重传可以关掉。）

弱网的时候（网络不好），udp比tcp更合适，因为在丢包的时候，tcp会重传。占用大量带宽资源，也不能保证实时。。

tcp与udp的适用场景。

1. udp适用场景：游戏（实时性。）
2. tcp有拥塞控制，即网络带宽能传多少就传多少。

tcp几个定时器？四个

tcp状态转移图

建立连接时所用函数：connect、accept。

断开连接时所用函数：close

四次挥手，断开连接：

连接成功后tcp只有一个状态，established

四次挥手的时候，没有客户端与服务端，只有主动和被动

一旦调用close，协议栈把fin位置1，被动方接收后，recv后返回0.（接收到空包。），然后被动地准备一个ack返回给对端，然后被动方再调用close，发送一个fin给主动端，主动段接收后再返回一个ack。。断开完成。

为什么断开需要四次？因为连接是双向的。互相断开。

可不可以三次断开连接？可以，若没有din_wit2..则三次 

fin_wait_1和last_ack状态肯定会消失，只是时间问题，若客户端出现大量fin_wait_2怎么办？客户端出现大量fin_wait_2状态时，服务端肯定有对应的close_wait状态。当服务器出现大量close_wait状态：这是因为服务器还没有lose（没有及时调用close，业务逻辑问题）。，在调用close之前，去关闭大量对应的fd、同步到数据库等操作，造成费时比较多。怎么解决呢？1要么先调用close，要么把业务信息抛到业务队列，线程池里面，让线程池去处理。

长时间出现fin_wait_2时（等两分钟。若对端长时间没有相应，会终止）。