linux内核tcp

1. 请问 Tcp/Ip协议在linux内核中架构模式 是什么样子的 回答的好的再补充分数。

这个问题问的好啊，我也有类似的问题。目前自己的答案是TCP/IP的每一层在linux内核中都是由不同的函数和数据结构组成的，不过目前我还没有整理出来。

2. linux下怎么设置tcp

Socket的send函数在执行时报EAGAIN的错误 当客户通过Socket提供的send函数发送大的数据包时，就可能返回一个EGGAIN的错误。该错误产生的原因是由于send 函数中的size变量大小超过了tcp_sendspace的值。tcp_sendspace定义了应用在调用send之前能够在kernel中缓存的数据量。当应用程序在socket中设置了O_NDELAY或者O_NONBLOCK属性后，如果发送缓存被占满，send就会返回EAGAIN的错误。 为了消除该错误，有三种方法可以选择： 1.调大tcp_sendspace，使之大于send中的size参数 ---no -p -o tcp_sendspace=65536 2.在调用send前，在setsockopt函数中为SNDBUF设置更大的值 3.使用write替代send，因为write没有设置O_NDELAY或者O_NONBLOCK 1. tcp 收发缓冲区默认值 [root@qljt core]# cat /proc/sys/net/ipv4/tcp_rmem 4096 87380 4161536 87380 ：tcp接收缓冲区的默认值 [root@qljt core]# cat /proc/sys/net/ipv4/tcp_wmem 4096 16384 4161536 16384 ： tcp 发送缓冲区的默认值 2. tcp 或udp收发缓冲区最大值 [root@qljt core]# cat /proc/sys/net/core/rmem_max 131071 131071：tcp 或 udp 接收缓冲区最大可设置值的一半。 也就是说调用 setsockopt(s, SOL_SOCKET, SO_RCVBUF, &rcv_size, &optlen); 时rcv_size 如果超过 131071，那么 getsockopt(s, SOL_SOCKET, SO_RCVBUF, &rcv_size, &optlen); 去到的值就等于 131071 * 2 = 262142 [root@qljt core]# cat /proc/sys/net/core/wmem_max 131071 131071：tcp 或 udp 发送缓冲区最大可设置值得一半。 跟上面同一个道理 3. udp收发缓冲区默认值 [root@qljt core]# cat /proc/sys/net/core/rmem_default 111616：udp接收缓冲区的默认值 [root@qljt core]# cat /proc/sys/net/core/wmem_default 111616 111616：udp发送缓冲区的默认值 . tcp 或udp收发缓冲区最小值 tcp 或udp接收缓冲区的最小值为 256 bytes，由内核的宏决定； tcp 或udp发送缓冲区的最小值为 2048 bytes，由内核的宏决定 setsockopt设置socket状态 1.closesocket（一般不会立即关闭而经历TIME_WAIT的过程）后想继续重用该socket： BOOL bReuseaddr=TRUE; setsockopt(s,SOL_SOCKET ,SO_REUSEADDR,(const char*)&bReuseaddr,sizeof(BOOL)); 2. 如果要已经处于连接状态的soket在调用closesocket后强制关闭，不经历TIME_WAIT的过程： BOOL bDontLinger = FALSE; setsockopt(s,SOL_SOCKET,SO_DONTLINGER,(const char*)&bDontLinger,sizeof(BOOL)); 3.在send(),recv()过程中有时由于网络状况等原因，发收不能预期进行,而设置收发时限： int nNetTimeout=1000;//1秒 //发送时限 setsockopt(socket，SOL_S0CKET,SO_SNDTIMEO，(char *)&nNetTimeout,sizeof(int)); //接收时限 setsockopt(socket，SOL_S0CKET,SO_RCVTIMEO，(char *)&nNetTimeout,sizeof(int)); 4.在send()的时候，返回的是实际发送出去的字节(同步)或发送到socket缓冲区的字节(异步);系统默认的状态发送和接收一次为8688字节(约为8.5K)；在实际的过程中发送数据 和接收数据量比较大，可以设置socket缓冲区，而避免了send(),recv()不断的循环收发： // 接收缓冲区 int nRecvBuf=32*1024;//设置为32K setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int)); //发送缓冲区 int nSendBuf=32*1024;//设置为32K setsockopt(s,SOL_SOCKET,SO_SNDBUF,(const char*)&nSendBuf,sizeof(int)); 5. 如果在发送数据的时，希望不经历由系统缓冲区到socket缓冲区的拷贝而影响程序的性能： int nZero=0; setsockopt(socket，SOL_S0CKET,SO_SNDBUF，(char *)&nZero,sizeof(nZero)); 6.同上在recv()完成上述功能(默认情况是将socket缓冲区的内容拷贝到系统缓冲区)： int nZero=0; setsockopt(socket，SOL_S0CKET,SO_RCVBUF，(char *)&nZero,sizeof(int)); 7.一般在发送UDP数据报的时候，希望该socket发送的数据具有广播特性： BOOL bBroadcast=TRUE; setsockopt(s,SOL_SOCKET,SO_BROADCAST,(const char*)&bBroadcast,sizeof(BOOL)); 8.在client连接服务器过程中，如果处于非阻塞模式下的socket在connect()的过程中可以设置connect()延时,直到accpet()被呼叫(本函数设置只有在非阻塞的过程中有显着的 作用，在阻塞的函数调用中作用不大) BOOL bConditionalAccept=TRUE; setsockopt(s,SOL_SOCKET,SO_CONDITIONAL_ACCEPT,(const char*)&bConditionalAccept,sizeof(BOOL)); 9.如果在发送数据的过程中(send()没有完成，还有数据没发送)而调用了closesocket(),以前我们一般采取的措施是"从容关闭"shutdown(s,SD_BOTH),但是数据是肯定丢失了，如何设置让程序满足具体应用的要求(即让没发完的数据发送出去后在关闭socket)？ struct linger { u_short l_onoff; u_short l_linger; }; linger m_sLinger; m_sLinger.l_onoff=1;//(在closesocket()调用,但是还有数据没发送完毕的时候容许逗留) // 如果m_sLinger.l_onoff=0;则功能和2.)作用相同; m_sLinger.l_linger=5;//(容许逗留的时间为5秒) setsockopt(s,SOL_SOCKET,SO_LINGER,(const char*)&m_sLinger,sizeof(linger)); 设置套接口的选项。 #include <winsock.h> int PASCAL FAR setsockopt( SOCKET s, int level, int optname, const char FAR* optval, int optlen); s：标识一个套接口的描述字。 level：选项定义的层次；目前仅支持SOL_SOCKET和IPPROTO_TCP层次。 optname：需设置的选项。 optval：指针，指向存放选项值的缓冲区。 optlen：optval缓冲区的长度。 注释： setsockopt()函数用于任意类型、任意状态套接口的设置选项值。尽管在不同协议层上存在选项，但本函数仅定义了最高的“套接口”层次上的选项。选项影响套接口的操作，诸如加急数据是否在普通数据流中接收，广播数据是否可以从套接口发送等等。 有两种套接口的选项：一种是布尔型选项，允许或禁止一种特性；另一种是整形或结构选项。允许一个布尔型选项，则将optval指向非零整形数；禁止一个选项optval指向一个等于零的整形数。对于布尔型选项，optlen应等于sizeof(int)；对其他选项，optval指向包含所需选项的整形数或结构，而optlen则为整形数或结构的长度。SO_LINGER选项用于控制下述情况的行动：套接口上有排队的待发送数据，且 closesocket()调用已执行。参见closesocket()函数中关于SO_LINGER选项对closesocket()语义的影响。应用程序通过创建一个linger结构来设置相应的操作特性： struct linger { int l_onoff; int l_linger; }; 为了允许SO_LINGER，应用程序应将l_onoff设为非零，将l_linger设为零或需要的超时值（以秒为单位），然后调用setsockopt()。为了允许SO_DONTLINGER（亦即禁止SO_LINGER），l_onoff应设为零，然后调用setsockopt()。 缺省条件下，一个套接口不能与一个已在使用中的本地地址捆绑（参见bind()）。但有时会需要“重用”地址。因为每一个连接都由本地地址和远端地址的组合唯一确定，所以只要远端地址不同，两个套接口与一个地址捆绑并无大碍。为了通知WINDOWS套接口实现不要因为一个地址已被一个套接口使用就不让它与另一个套接口捆绑，应用程序可在bind()调用前先设置SO_REUSEADDR选项。请注意仅在bind()调用时该选项才被解释；故此无需（但也无害）将一个不会共用地址的套接口设置该选项，或者在bind()对这个或其他套接口无影响情况下设置或清除这一选项。 一个应用程序可以通过打开SO_KEEPALIVE选项，使得WINDOWS套接口实现在TCP连接情况下允许使用“保持活动”包。一个WINDOWS套接口实现并不是必需支持“保持活动”，但是如果支持的话，具体的语义将与实现有关，应遵守RFC1122“Internet主机要求－通讯层”中第 4.2.3.6节的规范。如果有关连接由于“保持活动”而失效，则进行中的任何对该套接口的调用都将以WSAENETRESET错误返回，后续的任何调用将以WSAENOTCONN错误返回。 TCP_NODELAY选项禁止Nagle算法。Nagle算法通过将未确认的数据存入缓冲区直到蓄足一个包一起发送的方法，来减少主机发送的零碎小数据包的数目。但对于某些应用来说，这种算法将降低系统性能。所以TCP_NODELAY可用来将此算法关闭。应用程序编写者只有在确切了解它的效果并确实需要的情况下，才设置TCP_NODELAY选项，因为设置后对网络性能有明显的负面影响。TCP_NODELAY是唯一使用IPPROTO_TCP层的选项，其他所有选项都使用SOL_SOCKET层。 如果设置了SO_DEBUG选项，WINDOWS套接口供应商被鼓励（但不是必需）提供输出相应的调试信息。但产生调试信息的机制以及调试信息的形式已超出本规范的讨论范围。 setsockopt()支持下列选项。其中“类型”表明optval所指数据的类型。 选项 类型 意义 SO_BROADCAST BOOL 允许套接口传送广播信息。 SO_DEBUG BOOL 记录调试信息。 SO_DONTLINER BOOL 不要因为数据未发送就阻塞关闭操作。设置本选项相当于将SO_LINGER的l_onoff元素置为零。 SO_DONTROUTE BOOL 禁止选径；直接传送。 SO_KEEPALIVE BOOL 发送“保持活动”包。 SO_LINGER struct linger FAR* 如关闭时有未发送数据，则逗留。 SO_OOBINLINE BOOL 在常规数据流中接收带外数据。 SO_RCVBUF int 为接收确定缓冲区大小。 SO_REUSEADDR BOOL 允许套接口和一个已在使用中的地址捆绑（参见bind()）。 SO_SNDBUF int 指定发送缓冲区大小。 TCP_NODELAY BOOL 禁止发送合并的Nagle算法。 setsockopt()不支持的BSD选项有： 选项名 类型 意义 SO_ACCEPTCONN BOOL 套接口在监听。 SO_ERROR int 获取错误状态并清除。 SO_RCVLOWAT int 接收低级水印。 SO_RCVTIMEO int 接收超时。 SO_SNDLOWAT int 发送低级水印。 SO_SNDTIMEO int 发送超时。 SO_TYPE int 套接口类型。 IP_OPTIONS 在IP头中设置选项。 返回值： 若无错误发生，setsockopt()返回0。否则的话，返回SOCKET_ERROR错误，应用程序可通过WSAGetLastError()获取相应错误代码。 错误代码： WSANOTINITIALISED：在使用此API之前应首先成功地调用WSAStartup()。 WSAENETDOWN：WINDOWS套接口实现检测到网络子系统失效。 WSAEFAULT：optval不是进程地址空间中的一个有效部分。 WSAEINPROGRESS：一个阻塞的WINDOWS套接口调用正在运行中。 WSAEINVAL：level值非法，或optval中的信息非法。 WSAENETRESET：当SO_KEEPALIVE设置后连接超时。 WSAENOPROTOOPT：未知或不支持选项。其中，SOCK_STREAM类型的套接口不支持SO_BROADCAST选项，SOCK_DGRAM 类型的套接口不支持SO_DONTLINGER 、SO_KEEPALIVE、SO_LINGER和SO_OOBINLINE选项。 WSAENOTCONN：当设置SO_KEEPALIVE后连接被复位。 WSAENOTSOCK：描述字不是一个套接口。

3. Linux系统一般由哪4个部分组成

Linux系统一般有4个主要部分：内核、shell、文件系统和应用程序。内核、shell和文件系统一起形成了基本的操作系统结构，它们使得用户可以运行程序、管理文件并使用系统。

一、Linux内核

内核是操作系统的核心，具有很多最基本功能，如虚拟内存、多任务、共享库、需求加载、可执行程序和TCP/IP网络功能。Linux内核的模块分为以下几个部分：存储管理、CPU和进程管理、文件系统、设备管理和驱动、网络通信、系统的初始化和系统调用等。

二、Linuxshell

shell是系统的用户界面，提供了用户与内核进行交互操作的一种接口。它接收用户输入的命令并把它送入内核去执行，是一个命令解释器。另外，shell编程语言具有普通编程语言的很多特点，用这种编程语言编写的shell程序与其他应用程序具有同样的效果。

三、Linux文件系统

文件系统是文件存放在磁盘等存储设备上的组织方法。Linux系统能支持多种目前流行的文件系统，如EXT2、EXT3、FAT、FAT32、VFAT和ISO9660。

四、Linux应用程序

标准的Linux系统一般都有一套都有称为应用程序的程序集，它包括文本编辑器、编程语言、XWindow、办公套件、Internet工具和数据库等。

(3)linux内核tcp扩展阅读：

LINUX系统的特点

1、Linux是一款免费的操作系统，用户可以通过网络或其他途径免费获得，并可以任意修改其源代码。这是其他的操作系统所做不到的。

2、在Linux下通过相应的模拟器运行常见的DOS、Windows的程序。这为用户从Windows转到Linux奠定了基础。

3、Linux可以运行在多种硬件平台上，如具有x86、680x0、SPARC、Alpha等处理器的平台。此外Linux还是一种嵌入式操作系统，可以运行在掌上电脑、机顶盒或游戏机上。

4. 一般优化linux的内核，需要优化什么参数

作为高性能WEB服务器，只调整Nginx本身的参数是不行的，因为Nginx服务依赖于高性能的操作系统。

以下为常见的几个Linux内核参数优化方法。

• net.ipv4.tcp_max_tw_buckets

对于tcp连接，服务端和客户端通信完后状态变为timewait，假如某台服务器非常忙，连接数特别多的话，那么这个timewait数量就会越来越大。
毕竟它也是会占用一定的资源，所以应该有一个最大值，当超过这个值，系统就会删除最早的连接，这样始终保持在一个数量级。
这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。
CentOS7系统，你可以使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，
你可以适当把它调低，比如调整到8000，毕竟这个状态的连接太多也是会消耗资源的。
但你不要把它调到几十、几百这样，因为这种状态的tcp连接也是有用的，
如果同样的客户端再次和服务端通信，就不用再次建立新的连接了，用这个旧的通道，省时省力。

• net.ipv4.tcp_tw_recycle = 1

该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接，但如果把这样的连接重新利用起来岂不是更好。
所以该参数设置为1就可以让timewait状态的连接快速回收，它需要和下面的参数配合一起使用。

• net.ipv4.tcp_tw_reuse = 1

该参数设置为1，将timewait状态的连接重新用于新的TCP连接，要结合上面的参数一起使用。

• net.ipv4.tcp_syncookies = 1

tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，
假如客户端发送请求后直接断开和服务端的连接，不接收服务端发起的这个请求，服务端会重试多次，
这个重试的过程会持续一段时间（通常高于30s），当这种状态的连接数量非常大时，服务器会消耗很大的资源，从而造成瘫痪，
正常的连接进不来，这种恶意的半连接行为其实叫做syn flood攻击。
设置为1，是开启SYN Cookies，开启后可以避免发生上述的syn flood攻击。
开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn之前会要求client在短时间内回应一个序号，
如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法，于是不会发ack+syn给客户端，更涉及不到重试。

• net.ipv4.tcp_max_syn_backlog

该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，
该参数决定最多能记录几个这样的连接。在CentOS7，默认是256，当有syn flood攻击时，这个数值太小则很容易导致服务器瘫痪，
实际上此时服务器并没有消耗太多资源（cpu、内存等），所以可以适当调大它，比如调整到30000。

• net.ipv4.tcp_syn_retries

该参数适用于客户端，它定义发起syn的最大重试次数，默认为6，建议改为2。

• net.ipv4.tcp_synack_retries

该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改为2，可以适当预防syn flood攻击。

• net.ipv4.ip_local_port_range

该参数定义端口范围，系统默认保留端口为1024及以下，以上部分为自定义端口。这个参数适用于客户端，
当客户端和服务端建立连接时，比如说访问服务端的80端口，客户端随机开启了一个端口和服务端发起连接，
这个参数定义随机端口的范围。默认为32768 61000，建议调整为1025 61000。

• net.ipv4.tcp_fin_timeout

tcp连接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。
该参数定义不属于任何进程的该连接状态的超时时间，默认值为60，建议调整为6。

• net.ipv4.tcp_keepalive_time

tcp连接状态里，有一个是established状态，只有在这个状态下，客户端和服务端才能通信。正常情况下，当通信完毕，
客户端或服务端会告诉对方要关闭连接，此时状态就会变为timewait，如果客户端没有告诉服务端，
并且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时需要该参数来判定。
比如客户端已经断网了，但服务端上本次连接的状态依然是established，服务端为了确认客户端是否断网，
就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒，建议设置为30秒。

• net.ipv4.tcp_keepalive_intvl

该参数和上面的参数是一起的，服务端在规定时间内发起了探测，查看客户端是否在线，如果客户端并没有确认，
此时服务端还不能认定为对方不在线，而是要尝试多次。该参数定义重新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。
默认值为75秒，可以改为3秒。

• net.ipv4.tcp_keepalive_probes

第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测，但并没有定义一共探测几次才算结束。
该参数定义发起探测的包的数量。默认为9，建议设置2。
设置和范例
在Linux下调整内核参数，可以直接编辑配置文件/etc/sysctl.conf，然后执行sysctl -p命令生效

5. 怎么检测linux 内核 tcp发送缓冲区溢出

内核，是一个操作系统的核心。它负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。Linux作为一个自由软件， 在广大爱好者的支持下，内核版本不断更新。新的内核修订了旧内核的bug，并增加了许多新的特性。

6. Linux里面tcp协议属于四层服务吗

TCP/IP 的分层管理
TCP/IP 协议按照层次分为 4 层：应用层、传输层、网络层、数据链路层。 对于分层这个概念，大家一定不陌生，比如我们的分布式架构体系中会分为业务层、服务层、基础支撑层。比如docker，也是基于分层来实现。所以我们会发现，复杂的程序都需要分层，这个是软件设计的要求，每一层专注于当前领域的事情。如果某些地方需要修改，我们只需要把变动的层替换掉就行，一方面改动影响较少，另一方面整个架构的灵活性也更高。 最后，在分层之后，整个架构的设计也变得相对简单了。
分层负载

了解了分层的概念以后，我们再去理解所谓的二层负载、三层负载、四层负载、七层负载就容易多了。
一次 http 请求过来，一定会从应用层到传输层，完成整个交互。只要是在网络上跑的数据包，都是完整的。可以有下层没上层，绝对不可能有上层没下层。
二层负载

二层负载是针对 MAC，负载均衡服务器对外依然提供一个 VIP（虚 IP），集群中不同的机器采用相同 IP 地址，但是机器的 MAC 地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标 MAC 地址的方式将请求转发到目标机器实现负载均衡
二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址
三层负载均衡

三层负载是针对 IP，和二层负载均衡类似，负载均衡服务器对外依然提供一个 VIP（虚 IP），但是集群中不同的机器采用不同的 IP 地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过 IP 将请求转发至不同的真实服务器
三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址
四层负载均衡

四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。
四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器
七层负载均衡

七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、radius、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别来决定是否要进行负载均衡
比如：在nginx层做7层均衡，让一个uid的请求尽量落到同一个机器上

7. linux 内核怎么实现tcp nat 转换的

1.两个网络接口、一个内，一个外2.NAT转换（内）操作步骤：1.设置Linux内核支持ip数据包的转发：echo "1" > /proc/sys/net/ipv4/ip_forward2.加载实现NAT功能必要的内核模块：modprobe ip_tablesmodprobe ip_nat_ftpmodprobe ip_nat_ircmodprobe...

8. linux内核中tcp分组是怎么实现的

以前一直使用的网络通讯的函数都是工作在阻塞模式。在看connect实现源码时，突然想到tcp/ip的
三次握手在内核如何实现的，尤其是在非阻塞模式下式，涉及到等待对端回送ack包，而本端又要立即返
回，想来这种实现肯定是遵循某种规则或是将所有的相关函数组合起来。
查看一些网络通信书籍，可知果然如此。应用编程如果设置为非阻塞模式，则连接时，connect发送
SYN包后立即返回-EINPROGRESS，表示操作正在处理中；随后应用可以在connect返回后做一些其它的处理，
最后在select函数中来捕获socket的连接、读写、异常事件以触发相关操作，下面我们看看内核中的相关
实现：
一、tcp/ip连接的三次握手过程：
client SYN包---> server
client <---ACK包 server
client ACK包---> server
二、客户端支持
client发送2个包，一个SYN包，一个对服务器的响应ACK包。
client函数调用链：connect-->sys_connect->inet_stream_connect->tcp_connect...
看inet_stream_connect中实现的部分代码段：
...
switch (sock->state) {
...
/*此处调用tcp_connect函数发送SYN包*/
err = sk->prot->connect(sk, uaddr, addr_len);
if (err < 0) //出错则退出
goto out;
sock->state = SS_CONNECTING;
/* 此处仅设置socket的状态为SS_CONNECTING表示连接状态正在处理;
* 不同之处在于非阻塞情况下，返回值设置为-EINPROGRESS表示操作正在处理
* 而阻塞式情况则在获得ACK包后将返回值置为-EALREADY.
*/
err = -EINPROGRESS;
break;
}

timeo = sock_sndtimeo(sk, flags&O_NONBLOCK); //注意，如果此时设置了非阻塞选项，则timeo返回0
//如果socket对应的sock状态是SYN包已发送或收到SYN包并发送了ACK包，并等待对端发送第三此的ACK包
if ((1<<sk->state)&(TCPF_SYN_SENT|TCPF_SYN_RECV)) {
/* 错误返回码err前面已经设置 */
if (!timeo || !inet_wait_for_connect(sk, timeo))
/*注意上面所判断的2中情况，1、如果是非阻塞模式，则!timeo为1，则直接跳到out返回-EINPROGRESS结束connect函数
2、若为阻塞模式，则在inet_wait_for_connect函数中通过schele_timeout函数放弃cpu控制权睡眠，等待服务器端
发送ACK响应包后被唤醒继续处理。如果没有异常出现，则置socket状态为SS_CONNECTED，表示连接成功，正确返回
*/
goto out;

err = sock_intr_errno(timeo);
if (signal_pending(current)) /*处理未决信号*/
goto out;
}
...
sock->state = SS_CONNECTED;
err = 0;
out:
release_sock(sk);
return err;
...
上面的描述有一个问题：对服务器的响应ACK包是什么时候发送的？对于非阻塞模式，应该是应用处理过程中
的某个异步时间；对于阻塞模式，则是在inet_wait_for_connect函数中睡眠时处理。
即网卡在收到对方的ack包后，上传给对应的socket时发送服务器的响应ACK包
函数调用链为：netif_rx-->net_rx_action-->...(IP层处理)-->tcp_v4_rcv-->tcp_v4_do_rcv-->
tcp_rcv_state_process-->tcp_rcv_synsent_state_process-->tcp_send_synack-->tcp_transmit_skb...
发送SYN包后，socket对应的sock的状态变成TCPF_SYN_SENT，网卡收到服务器的ack传到tcp层时，根据TCPF_SYN_SENT
状态，做相关判断后再发送用于第三次握手的ack包。至此，将socket的状态改为连接建立，即TCP_ESTABLISHED。
具体的代码大家可以根据我提供的函数调用链查看。
注意，以TCPF_前缀开头的状态都表示是中间状态，而已TCP_为前缀的状态才是socket的一个相对稳定的状态。

这里有一个疑问，，根据接收处理源码，先前的SYN包应该发送给服务器的监听socket，而第三次握手似乎应该发送给
连接(未真正连接，因为三次握手还没完成呢)的socket，这个问题有待进一步确认
三、服务器端支持
服务器端此时必须是监听状态，则其函数调用链为：
netif_rx-->net_rx_action-->...(IP层处理)-->tcp_v4_rcv-->tcp_v4_do_rcv-->
tcp_rcv_state_process-->tcp_v4_conn_request-->tcp_v4_send_synack...
在tcp_v4_conn_request,中部分代码如下：
...
case TCP_LISTEN:
if(th->ack) /*监听时收到的ack包都丢弃？*/
return 1;
if(th->syn) {/*如果是SYN包,则调用tcp_v4_conn_request*/
if(tp->af_specific->conn_request(sk, skb) < 0)
return 1;

9. 如何优化 linux 内核参数设置tcp

其实也不能算是原创，日常工作的时候经常和这些参数打交道，遇到不明白的就去网上找到并记录下来，零零散散的记录了这么多，呵呵，如果你遇到没见过的参数，不妨来我这里找找，如果有不准确的地方，还请大家回复指出，谢谢 $ /proc/sys/net/core...