TCP技术

linux查看端口使用情况： netstat -na命令即可知道到当前的TCP连接状态。一般LISTEN、ESTABLISHED、TIME_WAIT是比较常见。

CLOSE_WAIT状态详解

首先我们知道，如果我们的Client程序处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！因为如果是Server端主动断掉当前连接的话，那么双方关闭这个TCP连接共需要四个packet：

Server ---< FIN ---< Client
       Server <--- ACK---Clientspan>

这时候Server端处于FIN_WAIT_2状态；而我们的程序处于CLOSE_WAIT状态。

       Server <--- FIN---Clientspan>

这时Client发送FIN给Server，Client就置为LAST_ACK状态。

Server ---< ACK ---< Client

Server回应了ACK，那么Client的套接字才会真正置为CLOSED状态。

当程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没有发FIN给Server，那么可能是在关闭连接之前还有许多数据要发送或者其他事要做，导致没有发这个FIN packet。
断开连接的时候，当发起主动关闭的左边这方发送一个FIN过去后，右边被动关闭的这方要回应一个ACK，这个ACK是TCP回应的，而不是应用程序发送的，此时，被动关闭的一方就处于CLOSE_WAIT状态了。如果此时被动关闭的这一方不再继续调用closesocket,那么他就不会发送接下来的FIN，导致自己老是处于CLOSE_WAIT。只有被动关闭的这一方调用了closesocket,才会发送一个FIN给主动关闭的这一方，同时也使得自己的状态变迁为LAST_ACK。

解决方式

重用本地地址和端口
要防止不断开辟新的端口，这可以通过设置SO_REUSEADDR套接字选项实现。
以前我总是一个端口不行，就换一个新的使用，所以导致让数千个端口进入CLOSE_WAIT状态。如果下次还发生这种尴尬状况，我希望加一个限定，只是当前这个端口处于CLOSE_WAIT状态！在调用**sockConnected = socket(AF_INET, SOCK_STREAM, 0);**之后，我们要设置该套接字的选项来重用：

/// 允许重用本地地址和端口:
/// 这样的好处是，即使socket断了，调用前面的socket函数也不会占用另一个，而是始终就是一个端口
/// 这样防止socket始终连接不上，那么按照原来的做法，会不断地换端口。
int nREUSEADDR = 1;
setsockopt(sockConnected, SOL_SOCKET,  SO_REUSEADDR, (constchar*)&nREUSEADDR,sizeof(int));

教科书上是这么说的：这样，假如服务器关闭或者退出，造成本地地址和端口都处于TIME_WAIT状态，那么SO_REUSEADDR就显得非常有用。
也许我们无法避免被冻结在CLOSE_WAIT状态永远不出现，但起码可以保证不会占用新的端口。

从容关闭|强行关闭设置SO_LINGER套接字选项实现。
默认情况下(Win2k)，SO_DONTLINGER套接字选项的是1；SO_LINGER选项是，linger为{l_onoff：0，l_linger：0}。
如果在发送数据的过程中(send()没有完成，还有数据没发送)而调用了closesocket()，以前我们一般采取的措施是“从容关闭”：因为在退出服务或者每次重新建立socket之前，我都会先调用

/// 先将双向的通讯关闭
shutdown(sockConnected, SD_BOTH);
/// 安全起见，每次建立Socket连接前，先把这个旧连接关闭
closesocket(sockConnected);

我们这次要这么做：设置SO_LINGER为零（亦即linger结构中的l_onoff域设为非零，但l_linger为0），便不用担心closesocket调用进入“锁定”状态（等待完成），不论是否有排队数据未发送或未被确认。这种关闭方式称为“强行关闭”，因为套接字的虚电路立即被复位，尚未发出的所有数据都会丢失。在远端的recv()调用都会失败，并返回WSAECONNRESET错误。在connect成功建立连接之后设置该选项：

linger m_sLinger;m_sLinger.l_onoff = 1;  
// (在closesocket()调用,但是还有数据没发送完毕的时候容许逗留)m_sLinger.l_linger = 0; 
// (容许逗留的时间为0秒)setsockopt(sockConnected,  SOL_SOCKET, SO_LINGER, (constchar*)&m_sLinger,sizeof(linger));

closesocket调用出现CLOSE_WAIT的原因很简单，就是某一方在网络连接断开后，没有检测到这个错误，没有执行closesocket，导致了这个状态的实现，这在TCP/IP协议的状态变迁图上可以清楚看到。同时和这个相对应的还有一种叫TIME_WAIT的。
另外，把SOCKET的SO_LINGER设置为0秒拖延（也就是立即关闭）在很多时候是有害处的。还有，把端口设置为可复用是一种不安全的网络编程方法。当主动关闭的一方发送FIN到被动关闭这边后，被动关闭这边的TCP马上回应一个ACK过去，同时向上面应用程序提交一个ERROR，导致上面的SOCKET的send或者recv返回SOCKET_ERROR，正常情况下，如果上面在返回SOCKET_ERROR后调用了 closesocket,那么被动关闭的者一方的TCP就会发送一个FIN过去，自己的状态就变迁到LAST_ACK.

TIME_WAIT状态详解

根据TCP协议，主动发起关闭的一方，会进入TIME_WAIT状态，持续2MSL(Max Segment Lifetime)，缺省为240秒，在这个post中简洁的介绍了为什么需要这个状态。
值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压2401000=240，000个 TIME_WAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个 request/response，一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少，因为 240秒的时间实在是忒长了点，对于Windows，修改注册表，在HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\ Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，一般认为不要少于60，不然可能会有麻烦。
对于大型的服务，一台server搞不定，需要一个LB(Load Balancer)把流量分配到若干后端服务器上，如果这个LB是以NAT方式工作的话，可能会带来问题。假如所有从LB到后端Server的IP包的 source address都是一样的(LB的对内地址），那么LB到后端Server的TCP连接会受限制，因为频繁的TCP连接建立和关闭，会在server上留下TIME_WAIT状态，而且这些状态对应的remote address都是LB的，LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口，还有一些其他端口缺省也不会用），每个LB上的端口一旦进入 Server的TIME_WAIT黑名单，就有240秒不能再用来建立和Server的连接，这样LB和Server最多也就能支持300个左右的连接。如果没有LB，不会有这个问题，因为这样server看到的remote address是internet上广阔无垠的集合，对每个address，60000多个port实在是够用了。
一开始我觉得用上LB会很大程度上限制TCP的连接数，但是实验表明没这回事，LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个，难道TIME_WAIT状态没起作用？用Net Monitor和netstat观察后发现，Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后，再来一个LB的XXXX端口的 SYN包，Server照样接收处理了，而是想像的那样被drop掉了。翻书，从书堆里面找出覆满尘土的大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》，中间提到一句，对于BSD-derived实现，只要SYN的sequence number比上一次关闭时的最大sequence number还要大，那么TIME_WAIT状态一样接受这个SYN，难不成Windows也算BSD-derived?有了这点线索和关键字 (BSD)，找到这个post，在NT4.0的时候，还是和BSD-derived不一样的，不过Windows Server 2003已经是NT5.2了，也许有点差别了。
做个试验，用Socket API编一个Client端，每次都Bind到本地一个端口比如2345，重复的建立TCP连接往一个Server发送Keep-Alive=false 的HTTP请求，Windows的实现让sequence number不断的增长，所以虽然Server对于Client的2345端口连接保持TIME_WAIT状态，但是总是能够接受新的请求，不会拒绝。那如果SYN的Sequence Number变小会怎么样呢？同样用Socket API，不过这次用Raw IP，发送一个小sequence number的SYN包过去，Net Monitor里面看到，这个SYN被Server接收后如泥牛如海，一点反应没有，被drop掉了。

soLinger

如果为0，且soLingOn打开，则不进入TIME_WAIT状态，直接发送RST包，关闭链接，缓存中的数据会丢失。此时对端收到RST应答，认为是异常重置，因此也会向上抛异常。如果非0，则会等待指定长度的时间再关闭。
建议关闭该功能，保证链路的正常关闭，即发起关闭时发送的是FIN包。

delay ack

nagle算法：导致小包无法及时响应，影响传输效率。

Socket

src（host：port）+dist（host：port）
三次握手均是与listen端口交互，数据交互那也就是跟listen端口了，accept（三次握手之后返回）只是新建了一个句柄，仍然使用监听端口，而不会在server分配新的端口。

linux实现

半连接队列：收到sync请求后加入的队列，大小取决于：max(64,/proc/sys/net/ipv4/tcp_max_syn_backlog)。不同版本的os会有些差异
全连接队列：accept后加入的队列，大小取决于：min(backlog, somaxconn) . backlog是在socket创建的时候传入的，somaxconn是一个os级别的系统参数

根据系统不同，溢出之后可能直接丢弃，或者响应一个reset。

表现：一旦溢出，从cpu、线程状态看起来都比较正常，但是压力上不去，在client看来rt也比较高（rt=网络+排队+真正服务时间），但是从server日志记录的真正服务时间来看rt又很短。
定位： netstat -s | egrep “listen|LISTEN” 查看是否有overflowed，drop >= overflowed

连接数上限

实际可以建立连接数的限制：系统支持的最大打开文件描述符数(包括socket连接):

[root@benegg.com ~]# cat /proc/sys/fs/file-max
580382

单个进程所能打开的最大文件描述符数:

[root@benegg.com ~]# ulimit -n
1024