Linux对大部分申请内存的请求都回复"yes"，以便能跑更多更大的程序。因为申请内存后，并不会马上使用内存。这种技术叫做Overcommit。

当内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程)，以便释放内存。

Overcommit和下面两个vm的配置有关系。

    vm.overcommit_ratio 
vm.overcommit_memory

overcommit_memory

    0 — 默认设置。个人理解：当应用进程尝试申请内存时，内核会做一个检测。内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。举个例子，比如1G的机器，A进程已经使用了500M，当有另外进程尝试malloc 500M的内存时，内核就会进行check，发现超出剩余可用内存，就会提示失败。
1 — 对于内存的申请请求，内核不会做任何check，直到物理内存用完，触发OOM杀用户态进程。同样是上面的例子，1G的机器，A进程500M，B进程尝试malloc 500M，会成功，但是一旦kernel发现内存使用率接近1个G(内核有策略)，就触发OOM，杀掉一些用户态的进程(有策略的杀)。
2 — 当 请求申请的内存 >= SWAP内存大小 + 物理内存 * N，则拒绝此次内存申请。解释下这个N：N是一个百分比，根据overcommit_ratio/100来确定，比如overcommit_ratio=50，那么N就是50%。

vm.overcommit_ratio

只有当vm.overcommit_memory = 2的时候才会生效，内存可申请内存为

    SWAP内存大小 + 物理内存 * overcommit_ratio/100

查看系统overcommit信息

    $ grep -i commit /proc/meminfo
CommitLimit:    517584 kB
Committed_AS:  3306488 kB

CommitLimit：最大能分配的内存(个人理解仅仅在vm.overcommit_memory=2时候生效)，具体的值是
SWAP内存大小 + 物理内存 * overcommit_ratio / 100

Committed_AS：当前已经分配的内存大小

TCP/IP 
TCP/IP是个协议组，可分为三个层次：网络层、传输层和应用层。 
在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。 
在传输层中有TCP协议与UDP协议。 
在应用层有:TCP包括FTP、HTTP、TELNET、SMTP等协议 
                 UDP包括DNS、TFTP等协议 
短连接 
连接->传输数据->关闭连接 
HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。 
也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。 
  
长连接 
连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。 
长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。 
  
http的长连接 
HTTP也可以建立长连接的，使用Connection:keep-alive，HTTP 1.1默认进行持久连接。HTTP1.1和HTTP1.0相比较而言，最大的区别就是增加了持久连接支持(貌似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。 
  
什么时候用长连接，短连接？ 
 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。 
  
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。 
  
总之，长连接和短连接的选择要视情况而定。 
发送接收方式 
1、异步 
报文发送和接收是分开的，相互独立的，互不影响。这种方式又分两种情况： 
(1)异步双工：接收和发送在同一个程序中，由两个不同的子进程分别负责发送和接收 
(2)异步单工：接收和发送是用两个不同的程序来完成。 
2、同步 
报文发送和接收是同步进行，既报文发送后等待接收返回报文。 同步方式一般需要考虑超时问题，即报文发出去后不能无限等待，需要设定超时时间，超过该时间发送方不再等待读返回报文，直接通知超时返回。 
  
在长连接中一般是没有条件能够判断读写什么时候结束，所以必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读相应长度的报文。 

Socket是什么 

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
主机 A 的应用程序要能和主机 B 的应用程序通信，必须通过 Socket 建立连接，而建立 Socket 连接必须需要底层 TCP/IP 协议来建立 TCP 连接。建立 TCP 连接需要底层 IP 协议来寻址网络中的主机。我们知道网络层使用的 IP 协议可以帮助我们根据 IP 地址来找到目标主机，但是一台主机上可能运行着多个应用程序，如何才能与指定的应用程序通信就要通过 TCP 或 UPD 的地址也就是端口号来指定。这样就可以通过一个 Socket 实例唯一代表一个主机上的一个应用程序的通信链路了。

建立通信链路
当客户端要与服务端通信，客户端首先要创建一个 Socket 实例，操作系统将为这个 Socket 实例分配一个没有被使用的本地端口号，并创建一个包含本地和远程地址和端口号的套接字数据结构，这个数据结构将一直保存在系统中直到这个连接关闭。在创建 Socket 实例的构造函数正确返回之前，将要进行 TCP 的三次握手协议，TCP 握手协议完成后，Socket 实例对象将创建完成，否则将抛出 IOException 错误。
与之对应的服务端将创建一个 ServerSocket 实例，ServerSocket 创建比较简单只要指定的端口号没有被占用，一般实例创建都会成功，同时操作系统也会为 ServerSocket 实例创建一个底层数据结构，这个数据结构中包含指定监听的端口号和包含监听地址的通配符，通常情况下都是“*”即监听所有地址。之后当调用 accept() 方法时，将进入阻塞状态，等待客户端的请求。当一个新的请求到来时，将为这个连接创建一个新的套接字数据结构，该套接字数据的信息包含的地址和端口信息正是请求源地址和端口。这个新创建的数据结构将会关联到 ServerSocket 实例的一个未完成的连接数据结构列表中，注意这时服务端与之对应的 Socket 实例并没有完成创建，而要等到与客户端的三次握手完成后，这个服务端的 Socket 实例才会返回，并将这个 Socket 实例对应的数据结构从未完成列表中移到已完成列表中。所以 ServerSocket 所关联的列表中每个数据结构，都代表与一个客户端的建立的 TCP 连接。

//////////////////////////////////////////////////////////////////////////////////////////////////////////

Linux TCP不同状态的连接数统计

方法一：利用netstat命令

统计 TIME_WAIT/CLOSE_WAIT/ESTABLISHED/LISTEN 等TCP状态的连接数

netstat -tan |grep ^tcp |awk '{++a[$6]} END{for (i in a) print i, a[i]}'

 

方法二：利用ss命令

ss -s

 

Total: 541 (kernel 0)
TCP:   77 (estab 27, closed 45, orphaned 0, synrecv 0, timewait 45/0), ports 0

Transport Total     IP        IPv6
*	  0         -         -
RAW	  0         0         0
UDP	  8         5         3
TCP	  32        31        1
INET	  40        36        4
FRAG	  0         0         0

 

TCP连接状态回顾

• CLOSED：初始状态，表示没有任何连接。
• LISTEN：Server端的某个Socket正在监听来自远方的TCP端口的连接请求。
• SYN_SENT：发送连接请求后等待确认信息。当客户端Socket进行Connect连接时，会首先发送SYN包，随即进入SYN_SENT状态，然后等待Server端发送三次握手中的第2个包。
• SYN_RECEIVED：收到一个连接请求后回送确认信息和对等的连接请求，然后等待确认信息。通常是建立TCP连接的三次握手过程中的一个中间状态，表示Server端的Socket接收到来自Client的SYN包，并作出回应。
• ESTABLISHED：表示连接已经建立，可以进行数据传输。
• FIN_WAIT_1：主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送FIN包（表示己方不再有数据需要发送），则进入FIN_WAIT_1状态，等待对方返回ACK包，此后还能读取数据，但不能发送数据。在正常情况下，无论对方处于何种状态，都应该马上返回ACK包，所以FIN_WAIT_1状态一般很难见到。
• FIN_WAIT_2：主动关闭连接的一方收到对方返回的ACK包后，等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收到了对方返回的ACK包后，便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包，所有常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时，则直接进入TIME_WAIT状态，无须经过FIN_WAIT_2状态。
• TIME_WAIT：主动关闭连接的一方收到对方发送的FIN包后返回ACK包（表示对方也不再有数据需要发送，此后不能再读取或发送数据），然后等待足够长的时间（2MSL）以确保对方接收到ACK包（考虑到丢失ACK包的可能和迷路重复数据包的影响），最后回到CLOSED状态，释放网络资源。
• CLOSE_WAIT：表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后（表示对方不再有数据需要发送），相应的返回ACK包，然后进入CLOSE_WAIT状态。在该状态下，若己方还有数据未发送，则可以继续向对方进行发送，但不能再读取数据，直到数据发送完毕。
• LAST_ACK：被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包（表示己方不再有数据需要发送），然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态，释放网络资源。
• CLOSING：比较罕见的例外状态。正常情况下，发送FIN包后应该先收到（或同时收到）对方的ACK包，再收到对方的FIN包，而CLOSING状态表示发送FIN包后并没有收到对方的ACK包，却已收到了对方的FIN包。有两种情况可能导致这种状态：其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送FIN包的情况；其二，如果ACK包丢失而对方的FIN包很快发出，也会出现FIN先于ACK到达。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

  最近在做一个大并发服务的测试（目前测到86万，当然有大量长连接，每天打的日志高到170多g，不打算继续测了），业务系统为反向代理ATS，服务的内容为动态域名，大部分的url很长，不过打开后的值只是0或1这样的标记。

    当服务器在几万并发时，一般不需要考虑TCP连接消耗内存的问题，但当服务器承载几十万并发时，会暴漏出各种的问题，因此不得不考虑TCP连接对内存资源的消耗，当然跑到86万的并发需要对业务系统、Centos做各种参数优化，牵涉面太多，今天只说TCP内存占用（由于线上系统干扰条件很多，无法特定的对某个参数去调试，只分享一下做过程的心得，抛砖引玉），出现的问题如下：

 

（内存不够用，kernel直接把ats的进程给杀掉了，然后out of socket memory）

 

  (跑着跑着，直接out of socket memory)

 

(tsar的内存监控数据) 

 

    每一个TCP连接都会有对应的socket封装，而每个socket都要占用一个fd，现在的业务系统大都采用epoll的网络I/O模型，他可以高效的处理大批量socket句柄，而这个socket句柄的对应的TCP读写缓存再加上一个TCP控制块就是单个TCP连接所消耗的内存，当然这个读写缓存的大小是根据系统的需要动态变化的，和TCP的滑动窗口大小成正相关。

对于tcp能够使用多少缓存，centos是会有全局控制的，例如我线上的服务器（内存62G，有15个G做内存cache使用）。

 

TCP 能够使用的内存：这三个值就是TCP使用内存的大小，单位是页，每个页是4K的大小，如下：

 

 

这三个值分别代表

Low：6179424   （6179424*4/1024/1024大概23g）

Pressure：8239232 （8239232*4/1024/1024大概31g）

High：12358848   （echo 12358848*4/1024/1024大概47g）

这个也是系统装后的默认取值，也就是说最大有47个g（75%的内存）可以用作TCP连接，这三个量也同时代表了三个阀值，TCP的使用小于第二个值时kernel不会有任何提示操作，当大于第二个值时进入压力模式，当高于第三个值时将不接受新的TCP连接，同时会报出“Out  of  socket memory”或者“TCP:too many of orphaned sockets”。

 

TCP 读缓存大小，单位是字节：第一个是最小值4K，第二个是默认值85K，第三个是最大值16M，如下：

 

 

 

这个可以在sysctl.conf中net.ipv4.tcp_rmem中进行调整。

 

TCP 写缓存大小，单位是字节：第一个是最小值4K，第二个是默认值64K，第三个是最大值16M，如下：

 

 

这个可以在sysctl.conf中net.ipv4.tcp_wmem中进行调整。

 

    也就是说一个TCP在三次握手建立连接后，最小的内存消耗在8K左右，最大的内存消耗在32M左右，你可以通过MTU估算MSS，然后算出一个滑动窗口有多少个MSS。现在可以进行简单计算了，按照系统TCP的全局控制，有47个g可用作内存缓存，假设按照默认的读写缓存计算，一个TCP连接占用149K加1K的tcp控制块共150K的内存，那么系统能承受最大的并发为 47*1024*1024/150 = 32万，当然这只是理论，一个TCP连接占用的内存实际是大小混用的，根据传输的文件大小以及网络状况动态调整。那么当前是什么情况呢，是有很多的长连接，而且每个请求的数据都很小，也就是说很有大量TCP连接只占了10K左右的内存，所以可以尝试更大的并发。

 好了，我顺着思路往下想，“Out  of  socket memory”除了业务系统恶意丢弃请求、或者孤儿套接字太多、或者fd（已经优化的很大了，不存在）用完了，就可能是为新的soket分配内存资源内存不够用了，因为在之前测试到30万左右的连接的时候出过这个问题，查看内存基本跑满，当时是把ats的logbuffer改小（动态连接一个url有时到45K的长度，于是当时把log buffer改的特别大）后就不报了，后来继续跑到50万左右又报错了，内存基本跑满，后把内存cache从30G调到了15G，再腾出15G给TCP连接及其与资源使用，跑到70万左右又不行了，大量这个错误。因为当前内存使用的很杂，有ats的内存缓存，有大量的孤儿Orphan soket（占用64K左右内存），还有大量的没有释放的TCP连接，还有ats的log等线程使用的内存，七七八八算下来，TCP能使用的内存不多，长连接、小链接、大链接的比例也不好计算，只能按照经验去尝试，目前看跑到70万已经到头了吧。

可是后来又想，系统对于刚开始建连接的时候可能是默认的内存占用，之后再动态调整，按照当前域名质量情况，大多数都是小的不能再小的请求，我是否可以更改默认TCP的读写缓存呢，于是调整，读写默认缓存各变为原来的一半分别是43K和32K，第二天晚高峰检查，跑到86万，没有出现问题，好了到此为止，不再测了。

 

 

 

总结：其实系统单纯能跑多大并发在乎全局fd和内存，但大并发下还能继续保持业务正常服务就是技术活儿了，每个业务系统的参数、操作系统的参数都得琢磨尝试,其余方面的优化小记有空再写。