第十八章 TCP的建立与终止
tcpdump
Tcpdump可以将网络中传送的数据报完截获下来进行分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息
就有点像Wireshark那个工具一样，只不过是命令行的，这里不作详细分析，直接给个实例：
每行输出格式如下： 源 > 目的：标志
这里的标志就是TCP首部中6个标志比特中的4个，下面是标志中5个字符的含义：
ack和urg将做特殊显示。
字段ack表示确认序号，只有在首部中ack标志为1时才显示。
win 64240 表示发端通告的窗口大小。
<mss 1400> 表示由发端指明的最大报文段长度选项，发端将不接收超过这个长度的TCP报文段，这通常的为了避免分段。
18.2 连接的建立与终止
18.2.3 建立连接协议
可以看到为了建立一条TCP连接具体做了什么：
1） 请求端发送一个syn段指明客户打算连接的服务器的端口，以及初始序号（ISN）。这个SYN段为报文段1
2） 服务器发回包含服务器的初始序号的SYN报文段作为应答，同时将确认序号设置为客户机的ISNN加1以对客户的SYN 报文段进行确认。一个SYN将占用一个序号。
3）客户端必须将确认序号置为服务器的ISN加1，以对服务器的SYN报文段进行确认。
发送第一个SYN的一段执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开
18.2.4 连接终止协议
终止需要经过4次握手。这是由于TCP的半关闭造成的。TCP是全双工的，因此每个方向必须单独关闭。
当一端收到一个FUN，它必须通知应用层另一端已经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。
收到一个FIN意味着在这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍然能发送数据。
首先进行关闭的一方执行主动关闭，另一方执行被动关闭。
18.2.5 正常的tcpdump输出
默认情况下tcpdump只在你显示SYN报文段时显示完成的序号，而对其后的序号则显示它们与初始序号的相对偏移值。
可以加上-S选项显示完整的序号。
18.3 连接建立的超时
假如服务器处于异常状态，客户端来连接。
假设第一次发送SYN时间是0，第2个syn与第一个间隔是5.8s，而第三个与第二个的间隔是24s
大部分伯克利系统将建立一个新连接的最长时间限制为75s。
18.3.1 第一次超时时间
18.3.2 服务类型字段
上图出现了[tos 0x10]，这是IP数据报内的服务类型字段。
18.4 最大报文段长度
MSS：表示TCP传往另一端的最大块数据的长度。当建立连接时，双方都要通告自己的MSS给对方。
MSS只能出现在SYN报文段中。如果一方不接收来自另一方的MSS值，则MSS就定位默认值536字节。
这样是为了尽量避免分片，提高网络利用率。
如果目的IP地址为非本地的，MSS通常设置默认值536,。那么如何区分本地还是非本地呢：
1） 目的IP地址的网络号和子网号都和我们相同，就是本地的
2） 网络号和子网号都不相同，则不是本地的。
3） 网络号相同，子网号不同，则可能是本地也可能非本地
MSS让主机限制另一端发送数据报的长度，加上主机也能控制它发送数据报的长度，这样可以以较小的MTU连接到一个网络上的主机避免分段。
18.5 TCP的半关闭
TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这就是半关闭。这个特性用的比较少。
shutdown可以选择具体关闭哪一端。如下示：
具体可以参考：http://www.cnblogs.com/xcywt/p/8127773.html
18.6 TCP的状态变迁图
可以参考：http://www.cnblogs.com/xcywt/p/8082428.html
也就是TCP的十一中状态了：
18.6.1 2MSL等待状态
TIME_WAIT状态也称为2MSL等待状态。
MSL：最大生存时间，任何报文段被丢弃前在网络内的最长时间。
IP数据报有限制生存时间的TTL，这个TTL是基于跳数的，而不是定时器。
对于宇哥具体实现所给定的MSL值，处理的原则是这样：一个TCP主动关闭，并发回最后一个ack，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可以让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。
在TIME_WAIT期间，定义这个连接的I插口（client和server的IP地址和端口号）不能再被使用，过了2MSL才能被使用。
但是大多数TCP实现强加了更为严格的限制，在2MSL期间，插卡中使用的本地端口在默认情况下不能再被使用。
设置选项SO_REUSRADDR就可以重复利用。
18.6.2 平静时间的等待
假如处于2MSL等待端口的主机出现故障，他会在MSL秒内重启。重启后还能连接吗？
RFC 793指出TCP在重启后的MSL内不能建立任何连接，这就称为平静时间（quiet time）。但是大部分的主机启动时间比MSL要长，座椅很少遵循这一原则
18.6.3 FIN_WAIT_2状态
如上，处于FIN_WAIT_2时，已经发送了一个FIN，对方也回复了ack。
只有在另一端的进程完成了关闭，我们这端才会进入TIME_WAIT状态。如果对方不close，我们将永远处于TIME_WAIT_2状态，对方处于close_wait状态。
有些伯克利实现 采用下面的方式来避免这个问题：关闭时不说明是半关闭，就设置一个定时器，如果这个连接空闲10分钟75秒，TCP将进入closed状态。
18.7 复位报文段
TCP首部中的RST比特用于“复位”的。一般来说，无论何时一个报文段发往基准的连接出现错误，TCP都将会发出一个复位报文段。
18.7.1 到不存在的端口的连接请求
连接请求到达时，目的端口没有进程正在监听，就会复位。
18.7.2 异常终止一个连接
正常释放连接是一方发送FIN。
但是也有可能发动一个复位报文段而不是FIN来中途释放一个连接，有时称为异常释放（abortive release）
异常终止一个连接对应用程序来说有两个优点：
1） 丢弃任何待发送数据，并立即发送复位报文段
2） RST的 接收方会区分另一端执行的是异常关闭还是正常关闭。
18.7.3 检测半打开连接
如果一方已经关闭或异常终止连接而另一方却还不知道，这时TCP连接称为半打开。
客户机突然掉电就会出现这个情况。、
18.8 同时打开
两个应用程序同时彼此执行主动打开的情况是可能的，虽然发送的概率很小。每一方必须发送一个SYN，且这些SYN必须传递给对方。这需要每一方使用一个对方熟知的端口作为本地端口。这又称为同时打开（simultaneous open）。
一个同时打开的连接需要交换4个报文段，比正常的三次握手多一个。另外，我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。
许多伯克利版的TCP实现都不能正确地支持同时打开。
18.9 同时关闭
通信双方同时关闭：
发出关闭命令后，两端均从ESTABLISHED编程TIME_WAIT_1。双方都发送一个FIN，两个FIN经过网络传送后分别到达另一端。收到FIN后，状态由FIN_WAIT_1变为closeing。并发出最后的ack。收到最后的ack后，状态变成了TIME_WAIT。
18.10 TCP选项
就是头部那个选项，可有可无的那个。具体可有见17章内容。
几乎每个SYN段中都会遇到MSS选项。
RFC 1323定义了一些新的选项。（这个暂时没有做深入理解）
18.11 TCP服务器是设计
大部分TCP服务器是并发的，当有新的连接请求到来时，服务器接收请求。并调用一个新进程来处理这个新的客户请求。
有的技术是用fork创建新进程，也有的可以创建新线程
18.11.1 TCP服务端口号
netstat可以查看：
-a表示显示网络中的所有主机端，而不仅仅是处于ESTABLISHED的主机端
-n标志将以点分十进制的形式显示IP地址，而不是通过DNS将地址转换成主机名。同时还要求显示端口号
18.11.2 限定的本地IP地址
假如我指定一个别人的IP地址进行作为服务器，那么该IP地址就成为处于listen服务器的本地IP地址，
当我们从以太网中的主机与这个服务器进行连接，连接请求被TCP模块拒绝。这个连接请求不会到达服务器的应用程序，因为它根据应用程序中指定的本地IP地址被内核中的TCP模块拒绝。
18.11.3 限定的源端IP地址
RFC 793中显示的接口函数允许一个服务器在执行被动打开时，可指明远端插口（等待一个特定的客户执行主动打开），也可以不指明远端插口（等待任何客户）
遗憾的是，大多数API 都不支持这么做，服务器必须不指明远端插口，而是等待连接请求的到来，然后检查客户端的IP地址和端口号。
18.11.4 呼入连接请求队列