TCP/IP协议

原文出自：

                http://blog.csdn.net/u010670619/article/details/50998260

                http://blog.csdn.net/onlyou930/article/details/7386484

                http://www.cnblogs.com/wulala1119/p/4749892.html

TCP协议原理：TCP每发送一个报文段，就启动一个定时器，如果在定时器超时之后还没有收到ACK确认，就重传该报文。 如图所示，数据包由A的缓冲区发往B，B在收到数据包以后，回发一个ACK确认包给A，之后A将该数据包从缓冲区释放。因此，该数据包会一直缓存在A的缓冲区，直到一个ACK确认为止。 

在TCP/IP协议中，TCP协议提供可靠的面向连接的服务；三次握手（建立连接）和四次挥手（关闭连接）；使用滑动窗口机制进行流量控制； 
三次握手的详细图解 
所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。如图1所示。 
 
图1 三次握手建立TCP连接的各状态 
（1）第一次握手：建立连接时，客户端A发送SYN包[SYN=1,seq=x]到服务器B，并进入SYN_SEND状态，等待服务器B确认。 
（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN，同时自己也发送一个SYN包，即SYN+ACK包[SYN=1,ACK=1,seq=y,ack=x+1]，此时服务器B进入SYN_RECV状态。 
（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK[ACK=1,seq=x+1,ack=y+1]，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据。 
三次握手完成后，客户端和服务器就建立了TCP连接。这时可以调用accept函数获得此连接。三次握手的目的是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号并交换TCP 窗口大小信息。在socket编程中，客户端执行connect()时，将会触发三次握手。 

四次挥手的详细图解 
TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。TCP要保证在所有可能的情况下使得所有的数据都能够被投递，当你关闭一个socket时，主动关闭一端的socket将进入TIME_WAIT状态，而被动关闭一方则转入CLOSED状态 ，这能够保证所有的数据都被传输。 
 
图2 四次挥手关闭TCP连接的各状态 
（1）首先A B端的TCP进程都处于established状态， 当A的应用程序传送完报文段，就会去主动关闭连接。A会停止发送报文段（但是还会接收），并向B发送[FIN = 1,seq=u]数据，之后进入FIN-WAIT-1状态； 
（2）B接收到A发送的请求之后，会通知应用进程，A已经不再发送数据，同时B会向A发送ACK确认数据[ACK=1,seq=v,ack=u+1 ]，B进入CLOSE-WAIT状态，A接收到B发送的数据之后，A进入FIN-WAIT-2状态；此时A到B方的连接已经关闭了（即半连接状态）。 
（3）当B的应用进程发现自己也没有数据需要传送，B应用进程就会发出被动关闭的请求，B此时向A发送[FIN=1,ACK=1,seq=w,ack=u+1]数据，并且进入LAST-ACK状态； 
（4）A接收到B发送的数据之后，向B发送ACK确认数据[ACK =1,seq=u+1,ack=w+1]，进入TIME-WAIT状态，等待2MSL之后正常关闭连接进入CLOSED状态；B接收到A发送的确认之后进入CLOSED状态。B到A方的连接关闭！至此，TCP连接才真正全部关闭！ 

 

总结：

*SYN：同步标志
同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

*ACK：确认标志
确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

*FIN：结束标志
带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

*RST：复位标志
复位标志有效。用于复位相应的TCP连接。

*URG：紧急标志
紧急(The urgent pointer) 标志有效。紧急标志置位，

*PSH：推标志
该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。

三次握手Three-way Handshake
一个虚拟连接的建立是通过三次握手来实现的
1. (B) --> [SYN] --> (A)
假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 标记的包，告诉A请求建立连接.
注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不能让外部任何主机主动建立连接。
2. (B) <-- [SYN/ACK] <--(A)
接着，A收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.
注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.
3. (B) --> [ACK] --> (A)
B收到SYN/ACK 包,B发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成
Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位
这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包

握手阶段：
序号         方向      seq      ack
1　　       A->B   10000     0
2              B->A   20000  10000+1=10001
3              A->B   10001  20000+1=20001

解释：
1：A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0
2：B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001
3：A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001

四次挥手Four-way Handshake
四次挥手用来关闭已建立的TCP连接
1. (B) --> ACK/FIN --> (A)
2. (B) <-- ACK <-- (A)
3. (B) <-- ACK/FIN <-- (A)
4. (B) --> ACK --> (A)
注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的

四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记

数据传输阶段：
序号　　        方向　　　　　　seq              ack                                size
23                    A->B                  40000         70000                             1514
24                   B->A                   70000         40000+1514-54=41460   54
25                   A->B                   41460         70000+54-54=70000     1514
26                   B->A                   70000         41460+1514-54=42920   54
解释：
23:B接收到A发来的seq=40000,ack=70000,size=1514的数据包
24:于是B向A也发一个数据包，告诉B，你的上个包我收到了。B的seq就以它收到的数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头，IP头，TCP头)，以证实B发过来的数据全收到了。
25:A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全到达。于是它再发一个数据包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收到的数据包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是头长，没数据项)。

其实在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度.如果从以太网包返回来计算所加的长度,就嫌走弯路了.
另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度.

 

几个问题： 
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报文。 
3.TCP报文段 
 
TCP报文段也分为首部和数据两部分，首部默认情况下一般是20字节长度，但在一些需求情况下，会使用“可选字段”，这时，首部长度会有所增加。 
TCP首部报文信息中，有一个状态控制码（Code，Control Flag），也叫标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下： 
URG：紧急比特（urgent）。当URG＝1时，表明紧急指针字段有效，代表该封包为紧急封包。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)， 且上图中的 Urgent Pointer 字段也会被启用。 
ACK：确认比特（Acknowledge）。只有当ACK＝1时确认号字段才有效，代表这个封包为确认封包。当ACK＝0时，确认号无效。 
PSH：（Push function）。若为1时，代表要求对方立即传送缓冲区内的其他对应封包，而无需等缓冲满了才送。 
RST：复位比特(Reset) 。当RST＝1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。 
SYN：同步比特(Synchronous)。SYN置为1，就表示这是一个连接请求或连接接受报文，通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。 
FIN：终止比特(Final)。用来释放一个连接。当FIN＝1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。

*传输数据过程*TCP报文的首部格式中确认号的计算： 
确认号是期望收到对方下一个报文段的第一个数据字节的序号。 
序列号等于前一个报文段的序列号与前一个报文段中数据字节的数量之和。

4.在已经成功建立连接的TCP连接，在以下四种情况时会导致TCP产生严重错误，发送RST包： 
1、端口未打开 
2、请求超时 
3、提前关闭 
4、在一个已关闭的socket上收到数据

 

 发送序号和确认序号问题

例： TCP建立连接的过程采用三次握手，已知第三次握手报文的发送序列号为1000，确认序列号为2000，请问第二次握手报文的发送序列号和确认序列号分别为？
答：看答案时请参考上面TCP连接建立的图。
客户端：发送X
服务端：发送Y， 确认X+1
客户端：发送X+1（1000），确认Y+1（2000）
可以反推第二次为1999,确认1000

SYN Flood 攻击原理及防御

SYN Flood是当前最流行的DoS（拒绝服务攻击）与DDoS（分布式拒绝服务攻击）的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。

原理：
问题出在TCP连接的三次握手中，恶意的攻击者大量发送SYN报文，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称作：服务器端受到了SYN Flood攻击（SYN洪水攻击）。
攻击方式：

1. Direct Attack 攻击方使用固定的源地址发起攻击，这种方法对攻击方的消耗最小
2. Spoofing Attack 攻击方使用变化的源地址发起攻击，这种方法需要攻击方不停地修改源地址，实际上消耗也不大
3. Distributed Direct Attack 这种攻击主要是使用僵尸网络进行固定源地址的攻击

防御方法：

1. 无效连接监视释放
   不停监视系统的半开连接和不活动连接，当达到一定阈值时拆除这些连接，从而释放系统资源。
2. 延缓TCB分配方法
   从前面SYN Flood原理可以看到，消耗服务器资源主要是因为当SYN数据报文一到达，系统立即分配TCB，从而占用了资源。而SYN Flood由于很难建立起正常连接，因此，当正常连接建立起来后再分配TCB则可以有效地减轻服务器资源的消耗。常见的方法是使用Syn Cache和Syn Cookie技术。
   Syn Cache技术：
   这种技术是在收到SYN数据报文时不急于去分配TCB，而是先回应一个SYN ACK报文，并在一个专用HASH表（Cache）中保存这种半开连接信息，直到收到正确的回应ACK报文再分配TCB。
   Syn Cookie技术：
   Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。
3. 使用SYN Proxy防火墙
   防火墙中提供一种SYN代理的功能，主要原理是对试图穿越的SYN请求进行验证后才放行。

 为什么TCP建立连接要三次握手

首先得回答三次握手的目的是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。
然后可以回答为什么两次握手不行，两次握手可能因为丢包而出现死锁，假设在两次握手场景中，C向S发送请求，S收到并发送确认请求给C，这时候S认为连接已经建立，并开始发送数据给C，但是那个确认请求丢包了，C不认为请求建立了，C当然会拒绝接受S发送来的数据，并且再去请求连接。这样，一个资源就死锁了。
最后回答握手当然可以四次五次一直握下去，但三次已经够了，就没有必要了。
总结下来一句话，主要目的防止在网络发生延迟或者丢包的情况下浪费资源。

 TCP传输阶段

滑动窗口以及拥塞控制

TCP协议作为一个可靠的面向流的传输协议，其可靠性和流量控制由滑动窗口协议保证，而拥塞控制则由控制窗口结合一系列的控制算法实现。

TCP断开阶段

 设置TIME_WAIT的原因

1. 可靠地实现TCP全双工连接的终止
   TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。
   因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态
2. 允许老的重复分节在网络中消逝
   TCP分节可能由于路由器异常而“迷途“，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。

 大量 TIME_WAIT 产生的原因及解决办法

原因：对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态。

解决办法：

1. 开启socket重用，允许将TIME_WAIT的socket重新用于TCP连接
2. 开启快速回收。

 大量CLOSE_WAIT产生的原因及解决办法

原因：对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接 关闭之后，程序里 没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。
解决办法：
具体问题具体解决，总结一句话就是在处理资源时一定要记住自己申请的资源要记得主动释放。

 为什么TCP断开连接要四次挥手

因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。

 其他

 出现RST包的原因

RST：TCP首部中的6个标志比特之一,表示重置连接、复位连接。

1. 服务器端口未打开而客户端来连接时
2. 在一个已关闭的SOCKET上收到数据
3. 请求超时
4. 提前关闭