Linux TCP参数优化 - 博客频道 - CSDN.NET
分类：Linux
本文档针对OOP8生产环境，具体优化策略需要根据实际情况进行调整；本文档将在以下几个方面来阐述如何针对RedHat Enterprise Linux进行性能优化。
1)& &&&Linux Proc文件系统，通过对Proc文件系统进行调整，达到性能优化的目的。
2)& &&&Linux性能诊断工具，介绍如何使用Linux自带的诊断工具进行性能诊断。
加粗斜体表示可以直接运行的命令。
下划线表示文件的内容。
二、/proc/sys/kernel/优化
1)& &&&/proc/sys/kernel/ctrl-alt-del
该文件有一个二进制值，该值控制系统在接收到ctrl+alt+delete按键组合时如何反应。这两个值分别是：&
0 值，表示捕获ctrl+alt+delete，并将其送至 init 程序；这将允许系统可以安全地关闭和重启，就好象输入shutdown命令一样。&
1 值，表示不捕获ctrl+alt+delete，将执行非正常的关闭，就好象直接关闭电源一样。
缺省设置：0
建议设置：
1) 防止意外按下ctrl+alt+delete导致系统非正常重启。
2)& &&&proc/sys/kernel/msgmax
&&该文件指定了从一个进程发送到另一个进程的消息的最大长度（bytes）。进程间的消息传递是在内核的内存中进行的，不会交换到磁盘上，所以如果增加该值，则将增加操作系统所使用的内存数量。
缺省设置：8192
3)& &&&/proc/sys/kernel/msgmnb
&&该文件指定一个消息队列的最大长度（bytes）。
缺省设置：16384
4)& &&&/proc/sys/kernel/msgmni
&&该文件指定消息队列标识的最大数目，即系统范围内最大多少个消息队列。
缺省设置：16
5)& &&&/proc/sys/kernel/panic
&&该文件表示如果发生“内核严重错误（kernel panic）”，则内核在重新引导之前等待的时间（以秒为单位）。
0 秒，表示在发生内核严重错误时将禁止自动重新引导。
缺省设置：0
6)& &&&proc/sys/kernel/shmall
&&该文件表示在任何给定时刻，系统上可以使用的共享内存的总量（bytes）。
缺省设置：2097152
7)& &&&/proc/sys/kernel/shmmax
&&该文件表示内核所允许的最大共享内存段的大小（bytes）。
缺省设置：
建议设置：物理内存 * 50%
实际可用最大共享内存段大小=shmmax * 98%，其中大约2%用于共享内存结构。
可以通过设置shmmax，然后执行ipcs -l来验证。
8)& &&&/proc/sys/kernel/shmmni
该文件表示用于整个系统的共享内存段的最大数目（个）。
缺省设置：4096
9)& &&&/proc/sys/kernel/threads-max
该文件表示内核所能使用的线程的最大数目。
缺省设置：2048
10) /proc/sys/kernel/sem
该文件用于控制内核信号量，信号量是System VIPC用于进程间通讯的方法。
建议设置：250 8
第一列，表示每个信号集中的最大信号量数目。
第二列，表示系统范围内的最大信号量总数目。
第三列，表示每个信号发生时的最大系统操作数目。
第四列，表示系统范围内的最大信号集总数目。
所以，（第一列）*（第四列）=（第二列）
以上设置，可以通过执行ipcs -l来验证。
11) 待续。。。
三、/proc/sys/vm/优化
1)& &&&/proc/sys/vm/block_dump
该文件表示是否打开Block Debug模式，用于记录所有的读写及Dirty Block写回动作。
缺省设置：0，禁用Block Debug模式
2)& &&&/proc/sys/vm/dirty_background_ratio
该文件表示脏数据到达系统整体内存的百分比，此时触发pdflush进程把脏数据写回磁盘。
缺省设置：10
3)& &&&/proc/sys/vm/dirty_expire_centisecs
该文件表示如果脏数据在内存中驻留时间超过该值，pdflush进程在下一次将把这些数据写回磁盘。
缺省设置：3000（1/100秒）
4)& &&&/proc/sys/vm/dirty_ratio
该文件表示如果进程产生的脏数据到达系统整体内存的百分比，此时进程自行把脏数据写回磁盘。
缺省设置：40
5)&&&&/proc/sys/vm/dirty_writeback_centisecs
该文件表示pdflush进程周期性间隔多久把脏数据写回磁盘。
缺省设置：500（1/100秒）
6)& &&&/proc/sys/vm/vfs_cache_pressure
该文件表示内核回收用于directory和inode cache内存的倾向；缺省&#表示内核将根据pagecache和swapcache，把directory和inode cache保持在一个合理的百分比；降低该值低于100，将导致内核倾向于保留directory和inode cache；增加该值超过100，将导致内核倾向于回收directory和inode cache。
缺省设置：100
7)& &&&/proc/sys/vm/min_free_kbytes
该文件表示强制Linux VM最低保留多少空闲内存（Kbytes）。
缺省设置：724（512M物理内存）
8)& &&&/proc/sys/vm/nr_pdflush_threads
该文件表示当前正在运行的pdflush进程数量，在I/O负载高的情况下，内核会自动增加更多的pdflush进程。
缺省设置：2（只读）
9)& &&&/proc/sys/vm/overcommit_memory
该文件指定了内核针对内存分配的策略，其值可以是0、1、2。
0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2， 表示内核允许分配超过所有物理内存和交换空间总和的内存（参照overcommit_ratio）。
缺省设置：0
10) /proc/sys/vm/overcommit_ratio
该文件表示，如果overcommit_memory=2，可以过载内存的百分比，通过以下公式来计算系统整体可用内存。
系统可分配内存=交换空间+物理内存*overcommit_ratio/100
缺省设置：50（%）
11) /proc/sys/vm/page-cluster
该文件表示在写一次到swap区的时候写入的页面数量，0表示1页，1表示2页，2表示4页。
缺省设置：3（2的3次方，8页）
12) /proc/sys/vm/swapiness
该文件表示系统进行交换行为的程度，数值（0-100）越高，越可能发生磁盘交换。
缺省设置：60
13) legacy_va_layout
该文件表示是否使用最新的32位共享内存mmap()系统调用，Linux支持的共享内存分配方式包括mmap()，Posix，System VIPC。
0， 使用最新32位mmap()系统调用。
1， 使用2.4内核提供的系统调用。
缺省设置：0
14) nr_hugepages
该文件表示系统保留的hugetlb页数。
15) hugetlb_shm_group
该文件表示允许使用hugetlb页创建System VIPC共享内存段的系统组ID。
16) 待续。。。
四、/proc/sys/fs/优化
1)& &&&/proc/sys/fs/file-max
该文件指定了可以分配的文件句柄的最大数目。如果用户得到的错误消息声明由于打开
文件数已经达到了最大值，从而他们不能打开更多文件，则可能需要增加该值。
缺省设置：4096
建议设置：65536
2)& &&&/proc/sys/fs/file-nr
该文件与 file-max 相关，它有三个值：&
已分配文件句柄的数目
已使用文件句柄的数目
文件句柄的最大数目
该文件是只读的，仅用于显示信息。
3)& &&&待续。。。
五、/proc/sys/net/core/优化
该目录下的配置文件主要用来控制内核和网络层之间的交互行为。
1） /proc/sys/net/core/message_burst
写新的警告消息所需的时间（以 1/10 秒为单位）；在这个时间内系统接收到的其它警告消息会被丢弃。这用于防止某些企图用消息“淹没”系统的人所使用的拒绝服务（Denial of Service）攻击。
缺省设置：50（5秒）
2） /proc/sys/net/core/message_cost
该文件表示写每个警告消息相关的成本值。该值越大，越有可能忽略警告消息。
缺省设置：5
3） /proc/sys/net/core/netdev_max_backlog
该文件表示在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
缺省设置：300
4） /proc/sys/net/core/optmem_max
该文件表示每个套接字所允许的最大缓冲区的大小。
缺省设置：10240
5） /proc/sys/net/core/rmem_default
该文件指定了接收套接字缓冲区大小的缺省值（以字节为单位）。
缺省设置：110592
6） /proc/sys/net/core/rmem_max
该文件指定了接收套接字缓冲区大小的最大值（以字节为单位）。
缺省设置：131071
7） /proc/sys/net/core/wmem_default
该文件指定了发送套接字缓冲区大小的缺省值（以字节为单位）。
缺省设置：110592
8） /proc/sys/net/core/wmem_max
该文件指定了发送套接字缓冲区大小的最大值（以字节为单位）。
缺省设置：131071
9） 待续。。。
六、/proc/sys/net/ipv4/优化
1)& &&&/proc/sys/net/ipv4/ip_forward
该文件表示是否打开IP转发。
缺省设置：0
2)& &&&/proc/sys/net/ipv4/ip_default_ttl
该文件表示一个数据报的生存周期（Time To Live），即最多经过多少路由器。
缺省设置：64
增加该值会降低系统性能。
3)& &&&/proc/sys/net/ipv4/ip_no_pmtu_disc
该文件表示在全局范围内关闭路径MTU探测功能。
缺省设置：0
4)& &&&/proc/sys/net/ipv4/route/min_pmtu
该文件表示最小路径MTU的大小。
缺省设置：552
5)&&&&/proc/sys/net/ipv4/route/mtu_expires
该文件表示PMTU信息缓存多长时间（秒）。
缺省设置：600（秒）
6)&&&&/proc/sys/net/ipv4/route/min_adv_mss
该文件表示最小的MSS（Maximum Segment Size）大小，取决于第一跳的路由器MTU。
缺省设置：256（bytes）
6.1 IP Fragmentation
1)/proc/sys/net/ipv4/ipfrag_low_thresh/proc/sys/net/ipv4/ipfrag_low_thresh
两个文件分别表示用于重组IP分段的内存分配最低值和最高值，一旦达到最高内存分配值，其它分段将被丢弃，直到达到最低内存分配值。
缺省设置：196608（ipfrag_low_thresh）
262144（ipfrag_high_thresh）
2)& &&&/proc/sys/net/ipv4/ipfrag_time
该文件表示一个IP分段在内存中保留多少秒。
缺省设置：30（秒）
6.2 INET Peer Storage
1)&&&&/proc/sys/net/ipv4/inet_peer_threshold
INET对端存储器某个合适值，当超过该阀值条目将被丢弃。该阀值同样决定生存
时间以及废物收集通过的时间间隔。条目越多，存活期越低，GC 间隔越短。
缺省设置：65664
2)& &&&/proc/sys/net/ipv4/inet_peer_minttl
条目的最低存活期。在重组端必须要有足够的碎片(fragment)存活期。这个最低
存活期必须保证缓冲池容积是否少于 inet_peer_threshold。该值以 jiffies为
单位测量。
缺省设置：120
3)& &&&/proc/sys/net/ipv4/inet_peer_maxttl
条目的最大存活期。在此期限到达之后，如果缓冲池没有耗尽压力的话(例如：缓
冲池中的条目数目非常少)，不使用的条目将会超时。该值以 jiffies为单位测量。
缺省设置：600
4)&&&&/proc/sys/net/ipv4/inet_peer_gc_mintime
废物收集(GC)通过的最短间隔。这个间隔会影响到缓冲池中内存的高压力。 该值
以 jiffies为单位测量。
缺省设置：10&
5)&&&&/proc/sys/net/ipv4/inet_peer_gc_maxtime
废物收集(GC)通过的最大间隔，这个间隔会影响到缓冲池中内存的低压力。 该值
以 jiffies为单位测量。
缺省设置：120
6.3 TCP Variables
1)& &&&/proc/sys/net/ipv4/tcp_syn_retries
该文件表示本机向外发起TCP SYN连接超时重传的次数，不应该高于255；该值仅仅针对外出的连接，对于进来的连接由tcp_retries1控制。
缺省设置：5
2)&&&&/proc/sys/net/ipv4/tcp_keepalive_probes
该文件表示丢弃TCP连接前，进行最大TCP保持连接侦测的次数。保持连接仅在
SO_KEEPALIVE套接字选项被打开时才被发送。
缺省设置：9（次）
3)& &&&/proc/sys/net/ipv4/tcp_keepalive_time
该文件表示从不再传送数据到向连接上发送保持连接信号之间所需的秒数。
缺省设置：7200（2小时）
4)&&&&/proc/sys/net/ipv4/tcp_keepalive_intvl
该文件表示发送TCP探测的频率，乘以tcp_keepalive_probes表示断开没有相应的TCP连接的时间。
缺省设置：75（秒）
5)& &&&/proc/sys/net/ipv4/tcp_retries1
该文件表示放弃回应一个TCP连接请求前进行重传的次数。
缺省设置：3
6)& &&&/proc/sys/net/ipv4/tcp_retries2
该文件表示放弃在已经建立通讯状态下的一个TCP数据包前进行重传的次数。
缺省设置：15
7)&&&&/proc/sys/net/ipv4/tcp_orphan_retries
在近端丢弃TCP连接之前，要进行多少次重试。默认值是 7 个，相当于 50秒–
16分钟，视 RTO 而定。如果您的系统是负载很大的web服务器，那么也许需
要降低该值，这类 sockets 可能会耗费大量的资源。另外参考
tcp_max_orphans。
8)& &&&/proc/sys/net/ipv4/tcp_fin_timeout
对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间。对方可能
会断开连接或一直不结束连接或不可预料的进程死亡。默认值为 60 秒。过去在
2.2版本的内核中是 180 秒。您可以设置该值，但需要注意，如果您的机器为负
载很重的web服务器，您可能要冒内存被大量无效数据报填满的风险，
FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1，因为它们最多只吃 1.5K&
的内存，但是它们存在时间更长。另外参考 tcp_max_orphans。
缺省设置：60（秒）
9)&&&&/proc/sys/net/ipv4/tcp_max_tw_buckets
系统在同时所处理的最大timewait sockets 数目。如果超过此数的话，
time-wait socket 会被立即砍除并且显示警告信息。之所以要设定这个限制，纯
粹为了抵御那些简单的 DoS 攻击，千万不要人为的降低这个限制，不过，如果
网络条件需要比默认值更多，则可以提高它(或许还要增加内存)。
缺省设置：180000
10) /proc/sys/net/ipv4/tcp_tw_recyle
打开快速 TIME-WAIT sockets 回收。除非得到技术专家的建议或要求，请不要随
意修改这个值。
缺省设置：0
11) /proc/sys/net/ipv4/tcp_tw_reuse
该文件表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接。
缺省设置：0
12) /proc/sys/net/ipv4/tcp_max_orphans
系统所能处理不属于任何进程的TCP sockets最大数量。假如超过这个数量，那
么不属于任何进程的连接会被立即reset，并同时显示警告信息。之所以要设定这
个限制，纯粹为了抵御那些简单的 DoS 攻击，千万不要依赖这个或是人为的降
低这个限制。
缺省设置：8192
13) /proc/sys/net/ipv4/tcp_abort_on_overflow
当守护进程太忙而不能接受新的连接，就向对方发送reset消息，默认值是false。
这意味着当溢出的原因是因为一个偶然的猝发，那么连接将恢复状态。只有在你确
信守护进程真的不能完成连接请求时才打开该选项，该选项会影响客户的使用。
缺省设置：０
14) /proc/sys/net/ipv4/tcp_syncookies
该文件表示是否打开TCP同步标签(syncookie)，内核必须打开了 CONFIG_SYN_COOKIES项进行编译。 同步标签(syncookie)可以防止一个套接字在有过多试图连接到达时引起过载。
缺省设置：0
15) /proc/sys/net/ipv4/tcp_stdurg
使用 TCP urg pointer 字段中的主机请求解释功能。大部份的主机都使用老旧的&
BSD解释，因此如果您在 Linux 打开它，或会导致不能和它们正确沟通。
缺省设置：0
16) /proc/sys/net/ipv4/tcp_max_syn_backlog
对于那些依然还未获得客户端确认的连接请求，需要保存在队列中最大数目。对于
超过 128Mb 内存的系统，默认值是 1024，低于 128Mb 的则为 128。如果
服务器经常出现过载，可以尝试增加这个数字。警告！假如您将此值设为大于
1024，最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE，以保持
TCP_SYNQ_HSIZE*16 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(如
果tcp_adv_win_scale 128Mb )则系统将忽略所有发送给自己
的ICMP ECHO请求或那些广播地址的请求。
缺省设置：1024
17) /proc/sys/net/ipv4/tcp_window_scaling
该文件表示设置tcp/ip会话的滑动窗口大小是否可变。参数值为布尔值，为1时表示可变，为0时表示不可变。tcp/ip通常使用的窗口最大可达到 65535 字节，对于高速网络，该值可能太小，这时候如果启用了该功能，可以使tcp/ip滑动窗口大小增大数个数量级，从而提高数据传输的能力。
缺省设置：1
18) /proc/sys/net/ipv4/tcp_sack
该文件表示是否启用有选择的应答（Selective Acknowledgment），这可以通过有选择地应答乱序接收到的报文来提高性能（这样可以让发送者只发送丢失的报文段）；（对于广域网通信来说）这个选项应该启用，但是这会增加对 CPU 的占用。
缺省设置：1
19) /proc/sys/net/ipv4/tcp_timestamps
该文件表示是否启用以一种比超时重发更精确的方法（请参阅 RFC 1323）来启用对 RTT 的计算；为了实现更好的性能应该启用这个选项。
缺省设置：1
20) /proc/sys/net/ipv4/tcp_fack
该文件表示是否打开FACK拥塞避免和快速重传功能。
缺省设置：1
21) /proc/sys/net/ipv4/tcp_dsack
该文件表示是否允许TCP发送“两个完全相同”的SACK。
缺省设置：1
22) /proc/sys/net/ipv4/tcp_ecn
该文件表示是否打开TCP的直接拥塞通告功能。
缺省设置：0
23) /proc/sys/net/ipv4/tcp_reordering
该文件表示TCP流中重排序的数据报最大数量。
缺省设置：3
24) /proc/sys/net/ipv4/tcp_retrans_collapse
该文件表示对于某些有bug的打印机是否提供针对其bug的兼容性。
缺省设置：1
25) /proc/sys/net/ipv4/tcp_wmem
该文件包含3个整数值，分别是：min，default，max
Min：为TCP socket预留用于发送缓冲的内存最小值。每个TCP socket都可以使用它。
Default：为TCP socket预留用于发送缓冲的内存数量，默认情况下该值会影响其它协议使用的net.core.wmem中default的 值，一般要低于net.core.wmem中default的值。
Max：为TCP socket预留用于发送缓冲的内存最大值。该值不会影响net.core.wmem_max，今天选择参数SO_SNDBUF则不受该值影响。默认值为128K。
缺省设置： 131072
26) /proc/sys/net/ipv4/tcp_rmem
该文件包含3个整数值，分别是：min，default，max
Min：为TCP socket预留用于接收缓冲的内存数量，即使在内存出现紧张情况下TCP socket都至少会有这么多数量的内存用于接收缓冲。&
Default：为TCP socket预留用于接收缓冲的内存数量，默认情况下该值影响其它协议使用的 net.core.wmem中default的 值。该值决定了在tcp_adv_win_scale、tcp_app_win和tcp_app_win的默认值情况下，TCP 窗口大小为65535。&
Max：为TCP socket预留用于接收缓冲的内存最大值。该值不会影响 net.core.wmem中max的值，今天选择参数 SO_SNDBUF则不受该值影响。
缺省设置： 174760
27) /proc/sys/net/ipv4/tcp_mem
该文件包含3个整数值，分别是：low，pressure，high
Low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。&
Pressure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。&
High：允许所有tcp sockets用于排队缓冲数据报的页面量。&
一般情况下这些值是在系统启动时根据系统内存数量计算得到的。
缺省设置： 49152
28) /proc/sys/net/ipv4/tcp_app_win
该文件表示保留max(window/2^tcp_app_win, mss)数量的窗口由于应用缓冲。当为0时表示不需要缓冲。
缺省设置：31
29) /proc/sys/net/ipv4/tcp_adv_win_scale
该文件表示计算缓冲开销bytes/2^tcp_adv_win_scale(如果tcp_adv_win_scale &; 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(如果tcp_adv_win_scale vi /etc/inittab，修改成如下
排名：第19553名
（61）（8）（1）（23）（2）（7）（1）（0）（1）（8）（25）（34）<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&随笔 - 10&
评论 - 29&
&&&&&&&&&&&
一、Linux服务器上11种网络连接状态:
& & & 图:TCP的状态机
通常情况下，一个正常的TCP连接，都会有三个阶段:1、TCP三次握手; 2、数据传送; 3、TCP四次挥手
注:以下说明最好能结合&图:TCP的状态机&来理解。
SYN: (同步序列编号,Synchronize Sequence Numbers)该标志仅在三次握手建立TCP连接时有效。表示一个新的TCP连接请求。
ACK: (确认编号,Acknowledgement Number)是对TCP请求的确认标志,同时提示对端系统已经成功接收所有数据。
FIN: (结束标志,FINish)用来结束一个TCP回话.但对应端口仍处于开放状态,准备接收后续数据。
1)、LISTEN:首先服务端需要打开一个socket进行监听，状态为LISTEN. /* The socket is listening for incoming connections. 侦听来自远方TCP端口的连接请求 */2)、SYN_SENT:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT.&/*The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求 */
3)、SYN_RECV:服务端应发出ACK确认客户端的SYN,同时自己向客户端发送一个SYN. 之后状态置为SYN_RECV&/* A connection request has been received from the network. 在收到和发送一个连接请求后等待对连接请求的确认 */
4)、ESTABLISHED: 代表一个打开的连接，双方可以进行或已经在数据交互了。/* The socket has an established connection. 代表一个打开的连接，数据可以传送给用户 */
5)、FIN_WAIT1:主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态./* The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求，或先前的连接中断请求的确认 */
6)、CLOSE_WAIT:被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT.&/* The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求 */
7)、FIN_WAIT2:主动关闭端接到ACK后，就进入了FIN-WAIT-2 ./* Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程TCP等待连接中断请求 */
8)、LAST_ACK:被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK .&/* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的连接中断请求的确认 */
9)、TIME_WAIT:在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态。/* The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程TCP接收到连接中断请求的确认 */
10)、CLOSING: 比较少见./* Both sockets are shut down but we still don&t have all our data sent. 等待远程TCP对连接中断的确认 */
11)、CLOSED: 被动关闭端在接受到ACK包后，就进入了closed的状态。连接结束./* The socket is not being used. 没有任何连接状态 */TIME_WAIT状态的形成只发生在主动关闭连接的一方。　　主动关闭方在接收到被动关闭方的FIN请求后，发送成功给对方一个ACK后,将自己的状态由FIN_WAIT2修改为TIME_WAIT，而必须再等2倍 的MSL(Maximum Segment Lifetime,MSL是一个数据报在internetwork中能存在的时间)时间之后双方才能把状态 都改为CLOSED以关闭连接。目前RHEL里保持TIME_WAIT状态的时间为60秒。当然上述很多TCP状态在系统里都有对应的解释或设置,可见man tcp
二、关于长连接和短连接:　　通俗点讲，短连接就是一次TCP请求得到结果后,连接马上结束.而长连接并不马上断开,而一直保持着,直到长连接TIMEOUT(具体程序都有相关参数说明).长连接可以避免不断的进行TCP三次握手和四次挥手.长连接(keepalive)是需要靠双方不断的发送探测包来维持的,keepalive期间服务端和客户端的TCP连接状态是ESTABLISHED.目前http 1.1版本里默认都是keepalive(1.0版本默认是不keepalive的)，ie6/7/8和firefox都默认用的是http 1.1版本了(如何查看当前浏览器用的是哪个版本，这里不再赘述)。Apache,java
　　一个应用至于到底是该使用短连接还是长连接，应该视具体情况而定。一般的应用应该使用长连接。
tcp 四次挥手
　　TCP协议有一个优雅的关闭（graceful close）机制，以保证应用程序在关闭连接时不必担心正在传输的数据会丢失。如第4.5节的压缩示例程序所示，这个机制还设计为允许两个方向的数据传输相互独立地终止。关闭机制的工作流程是：应用程序通过调用连接套接字的close()方法或shutdownOutput()方法表明数据已经发送完毕。此刻，底层的TCP实现首先将留存在SendQ队列中的数据传输出去（还要依赖于另一端RecvQ队列的剩余空间），然后向另一端发送一个关闭TCP连接的握手消息。该关闭握手消息可以看作是流终止标志：它告诉接收端TCP不会再有新的数据传入RecvQ队列了。（注意，关闭握手消息本身并没有传递给接收端应用程序，而是通过read()方法返回-1来指示其在字节流中的位置。）正在关闭的TCP将等待其关闭握手消息的确认信息，该确认信息表明在连接上传输的所有数据已经安全地传输到了RecvQ中。只要收到了确认消息，该连接就变成"半关闭（Half closed）"状态。直到连接的另一个方向上收到了对称的握手消息后，连接才完全关闭--也就是说，连接的两端都表明它们再没有数据要发送了。
　　TCP连接的关闭事件序列可能以两种方式发生：一种方式是先由一个应用程序调用close()方法（或shutdownOutput()方法），并在另一端调用close()方法之前完成其关闭握手消息；另一种方式是两端同时调用close()方法，它们的关闭握手消息在网络上交叉传输。图6.10展示了以第一种方式关闭连接时，底层实现中的事件序列。关闭握手消息已经发送，套接字数据结构的状态也已经设置为"Closing"（专业术语称为"FIN_WAIT_1"），然后close()调用返回。完成这些工作后，将禁止在该Socket上的任何读写操作（会抛出异常）。当收到关闭握手确认消息后，套接字数据结构的状态则改变为"半关闭"（专业术语称为"FIN_WAIT_2"），这种状态将一直持续，直到接收到另一端的关闭握手消息
　　关闭TCP连接的最后微妙之处在于对Time-Wait状态的需要。TCP规范要求在终止连接时，两端的关闭握手都完成后，至少要有一个套接字在Time-Wait状态保持一段时间。这个要求的提出是由于消息在网络中传输时可能延迟。如果在连接两端都完成了关闭握手后，它们都移除了其底层数据结构，而此时在同样一对套接字地址之间又立即建立了新的连接，那么前一个连接在网络上传输时延迟的消息就可能在新连接建立后到达。由于其包含了相同的源地址和目的地址，旧消息就会被错误地认为是属于新连接的，其包含的数据就可能被错误地分配到应用程序中。
　　虽然这种情形可能很少发生，TCP还是使用了包括Time-Wait状态在内的多种机制对其进行防范。Time-Wait状态用于保证每个TCP连接都在一段平静时间内结束，这期间不会有数据发送。平静时间的长度应该等于分组报文在网络上存留的最长时间的两倍。因此，当一个连接完全结束（即套接字数据结构离开Time-Wait状态并被删除），并为同样一对地址上的新连接清理道路后，就不会再有旧实例发送的消息还存留在网络中。实际上，平静时间的长度要依赖于具体实现，因为没有机制能真正限制分组报文在网络上能够延迟的时间。通常使用的时间范围是4分钟减到30秒，或更短。
　　Time-Wait状态最重要的作用是，只要底层套接字数据结构还存在，就不允许在相同的本地端口上关联其他套接字。尤其是试图使用该端口创建新的Socket实例时，将抛出IOException异常。
1、建立连接协议（三次握手）（1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。
2、连接终止协议（四次挥手）　 　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。　（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。　（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。　（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。　（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。
CLOSED: 这个没什么好说的了，表示初始状态。
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_RCVD: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED：这个容易理解了，表示连接已经建立了。
FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
最后有2个问题的回答，我自己分析后的结论（不一定保证100%正确）:
1、 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
2、 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？这是因为：虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
阅读(...) 评论()