Posix API与网络协议栈的实现原理

1. TCP三次握手过程？

2. TCP四次挥手过程？

3. 为什么建立连接需要三次握手，而断开 连接需要四次握手？

4. TIME_WAIT状态持续时间及原因

5.大量的time_wait于close_wait

6. 超时重传和快速重传

7. TCP首部长度，有哪些字段

8. TCP在listen时的参数backlog的意义

9. Accept发生在三次握手的哪一步？

10. 三次握手过程中有哪些不安全性

11.TCP与UDP的区别

udp主要用在哪里：

1.大量数据传输，(比如迅雷vip，大量下载的时候其他人会很卡，因为udp没有拥塞控制)

2.实时性。

3.dns协议。(浏览器打开www.baidu.com获取ip地址的过程采用的是udp。

udp的缺点有哪些：

1.不稳定                          

建立连接的过程:

udp不建立连接，没有三次握手，也可以调用connect()函数，udp的这个connect()函数没有发送具体的数据，仅此尝试一下这条链路是不是通的，对方的这个ip地址和端口号有没有存在。如果返回是个正数成功的话，那么接下来调用sendto()成功的概率要比不调用connect()高很多。

tcp在发送数据之前是要调用connect()函数建立连接的，服务器必须要处在listen()的状态才能接收连接。

我们所调用的这些API都是在应用程序里面调用的。三次握手(四次挥手)的过程是发生在TCP/IP协议栈和协议栈之间。这是协议栈帮忙实现的，跟我们的应用程序没有关系。 

send()这个函数干的事情就是将数据从用户空间copy到协议栈里面。再次调用send()也只是继续copy到协议栈里面的send_buffer里面。 至于这个数据怎么到对方的协议栈里面的，就是需要tcp的确认机制，慢启动，拥塞控制...等。

                                  commit_skb()

调用connect()函数的时候，此时应用程序会把本机的ip和port。copy到协议栈里面，协议栈会自己准备一个包(SYN)(TCP头八个状态位里面把SYN状态位置1），然后把这个数据发给对端。服务端会返回一个ACK 和一个SYN。并且保存服务端的一些信息(因为服务端只有一个，客户端可以有n多个) ，当第三次握手来了之后，服务端会拿着这个信息和去半连接队列里面对比有没有这个节点，然后再把这个节点拿到全连接队列里面来(这个节点不是拷贝，是移动）。（进入全连接队列的前提条件是第三次握手过来，并且在半连接队列里面有，这两个条件同时满足，才进入全连接队列）。accept()这个函数只干两件事情，1. 从accept队列里面拿出一个节点，2. 位这个节点分配一个与之对应的fd，然后返回这个fd。（如果此时这个全连接队列里面没有节点，accept会进入条件等待，等待全连接队列里面有节点，此时会进入阻塞状态）。如果此时这个fd被设置为非阻塞fcntl(fd,noblock),此时accept就会立即返回-1。

第三次握手的时候通过什么找到半连接队列里面的对应的节点？  

通过五元组(sip , dip , sport , dport ,porto)，这些信息在tcp/ip协议头和ip协议头里面都有。目的ip和目的端口都是一样的，只需要拿sip和sport对比一下就知道了。

 半连接队列里面的节点也叫做TCP控制块(TCB)

半连接队列节点的声明周期它有多长?

tcp的(11个状态)状态是存在半连接队列的节点里面的，伴随着连接过程的整个生命周期。

脏数据:  多个客户端同时sendto给一个fd的时候，recvfrom的数据可能会乱序。 一个fd对应一个recvbuffer。   在这个recvbuffer里面无法区分数据是哪个客户端来的。

怎么解决udp并发的问题：                       模拟tcp

1. recvfrom(&addr) 接收到第一帧的信息，拿到他的ip地址和端口号。

2. 新建一个fd,调用sendto(fd ,...) 给对端发。 出现了一个fd对应一个客户端的现象。

如果接收到第一帧包不对的话就返回，然后超时重发。

TCP的超时重传机制，没发送一个包，会启动一个200ms的定时器。比如当检测到3号包没到的话，将重新发送3号以及后面的所有包。(这也是tcp缺点之一: 确认时间周期长，重传的时候会重传那些即使已经收到的包---重发的次数有点多) ack就是一个数字，可以理解为是多少号包以前的全部收到了。 

TCP的超时重传只会在发送方启动一个定时器，对方是不会启动定时器的，如果对方回的这个ACK丢失了，那么也会引起发送方的超时重传。

 tcp一开始是慢启动的，最先是指数级增长，到一定程度后线性增长，当线性增长到达最大值之后砍一半，继续线性增长，后面这个过程叫拥塞控制(发包的数量)。

调用close、shutdown 、connect、send这四个函数的时候会有一个数据发送的过程

 当对端close的时候，epoll里面就会触发EPOLLRDHUP。如果两端都close了，自己也发送出去了FIN并且也收到了ACK，那么此时如果这个fd还在EPOLL里面。那么这一步就会触发EPOLLHUP

大量的time_wait怎么办?

首先是主动调用close()，主动方才有time_wait。如果作为服务方，出现大量的time_wait是不正常的现象(你的服务器代码里面出现了主动调用close的现象)。(先检查你的逻辑看看调用close的地方是不是正常的，如果不是正常的就把业务代码改一下。如果是正常的，可以通过setsockopt(REUSE)，设置为重用。当这个TCB设置为重用之后，这个TCP不会被释放，会再次拿来使用。能够在一定限度上去减少time_wait。

大量的close_wait怎么办？

当recv返回0，可以判断对端关闭了。此时进入close_wait状态。这时候出现大量的close_wait状态是因为服务端调用close这个过程延迟了。(服务端知道客户端断开连接了，但是在服务端调用close之前可能需要对客户端释放一些信息，还需要向客户端发送一些数据，这个逻辑代码可能有点长，延迟了close的调用)。（还有一些特殊情况就是你在服务端没有调用close)

这种时候就要看看你recv返回0之后你调用close是不是正确的时机。当recv返回0之后应该是立即调用close。然后把业务代码的解析和释放可以抛给另外一个线程，把这个fd(客户端)的信息抛给另外一个线程去释放业务代码。不应该在recv返回0这个流程里面处理。可以做成异步处理。

fin_wait_2状态能不能终止？

比如现在进入了fin_wait_2状态，等待着对方调用close，但是对方迟迟不调用close。所以此时出现了很多的这种close_wait 和 fin_wait_2。 (答案是没有) 。 当客户端调用完close之后，客户端能做的事情已经做完了，此时需要等待对方调用close。在逻辑代码上面已经没办法处理了。真的要强行禁止，只能kill。

send/recv

UDP协议