TCP详解(2):三次握手与四次挥手

  TCP(Transmission Control Protocol,传输控制协议)是基于连接的协议,也就是说,在正式收发数据前,必须和对方建立可靠的连接,就好像你给别人打电话,必须等线路接通了、对方拿起话筒建立了连接才能相互通话。
  一个TCP连接必须要经过三次“对话”才能建立起来,其中的过程非常复杂,我们这里只做简单、形象的介绍,你只要做到能够理解这个过程即可。我们来看看这三次对话的简单过程:主机A向主机B发出连接请求数据包:“我想给你发数据,可以吗?”,这是第一次对话;主机B向主机A发送同意连接和要求同步(同步就是两台主机一个在发送,一个在接收,协调工作)的数据包:“可以,你什么时候发?”,这是第二次对话;主机A再发出一个数据包确认主机B的要求同步:“我现在就发,你接着吧!”,这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步,经过三次“对话”之后,主机A才向主机B正式发送数据。

   

1. 建立连接三次握手
  TCP用三次握手(three-way handshake)过程创建一个连接。在连接创建过程中,很多参数要被初始化,例如序号被初始化以保证按序传输和连接的强壮性。
  一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字(socket)然后监听来自另一方的连接,这就是通常所指的被动打开(passive open)。服务器端被被动打开以后,用户端就能开始创建主动打开(active open)。
  1)客户端通过向服务器端发送一个SYN来创建一个主动打开,作为三路握手的一部分。客户端把这段连接的序号设定为随机数 A。
  2)服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK 的确认码应为 A+1,SYN/ACK 包本身又有一个随机序号 B。
  3)最后,客户端再发送一个ACK。当服务端受到这个ACK的时候,就完成了三路握手,并进入了连接创建状态。此时包序号被设定为收到的确认号 A+1,而响应则为 B+1。
   

  Win:窗口字段明确指出现在允许对方发送的数据量(经常变化)
  Len:TCP数据段长度
  MSS(Maximum Segment Size):最大报文段长度,即每个TCP报文段中的数据字段的最大长度.这里需要在握手的时候进行协商,双方都给出MSS,最后以最小MSS确定为最终的MSS。IP数据报最大传输单位为MTU(Maximum Transmission Unit,Effect of short board),对于大多数使用以太网的局域网来说,MTU=1500。MSS往往基于MTU计算出来,通常MSS=MTU-sizeof(IP Header)-sizeof(TCP Header)=1500-20-20=1460,如果服务器MSS=1460,而客户端的MSS=1440,最终为1440。

  在TCP的三次握手中,不仅是建立了连接,还让双方交换了有效信息,过程如下:
  1) 嗨~ , 这是我sequence number和MSS
  2) 我收到啦~, 这是我sequence number和MSS
  3) 我也收到~

为什么需要三次握手?
  简单地说,就是要保证在一段有效时间内,双方收到对方的有效信息。
  一个简单例子,A发给B,B回复A,如果A不再回复B,B如何知道A收到了自己的信息?
  谢希仁版《计算机网络》中的例子是这样的,“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”。
  不管哪个例子,都是为了满足”在不可靠信道上可靠地传输信息”这一需求。请注意这里的本质需求,信道不可靠,数据传输要可靠。还是那句话,就是要保证在一段有效时间内,双方收到对方的有效信息。

SYN攻击
  在三次握手过程中,服务器发送SYN-ACK之后,收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后,服务器转入ESTABLISHED状态.
SYN攻击就是攻击客户端在短时间内伪造大量不存在的IP地址,向服务器不断地发送syn包,服务器回复确认包,并等待客户的确认,由于源地址是不存在的,服务器需要不断的重发直 至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢,严重者引起网络堵塞甚至系统瘫痪。
  SYN攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击:
netstat -n -p TCP | grep SYN_RECV
  一般较新的TCP/IP协议栈都对这一过程进行修正来防范SYN攻击,修改TCP协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.
  但是不能完全防范SYN攻击。

Socket状态对应
  Socket API 和 TCP 协议中各个状态是如何对应的呢?我们可以通过下图来看:

  

2. 断开连接四次挥手
  由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。比如服务器收到一个FIN只意味着客户端不再发送数据,但它还可以向客户端发送数据,当服务器不再发数据了,他也要向客户端发送FIN。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
  
    

四次挥手过程如下:
  1)客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送。
  2)服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。
  3)服务器B关闭与客户端A的连接,发送一个FIN给客户端A。
  4)客户端A发回ACK报文确认,并将确认序号设置为收到序号加1。

状态变化

  

  FIN_WAIT_1: 当SOCKET在ESTABLISHED状态,主动关闭连接时,向对方发送FIN报文,此时该SOCKET进入到FIN_WAIT_1状态。当对方回应ACK报文后,则进入到FIN_WAIT_2状态。(主动方)
  FIN_WAIT_2:处于FIN_WAIT_2状态下的SOCKET为半连接状态,等待对方发起断开要求,(注意对方可以在断开时捎带信息)稍后再关闭连接。(主动方)
  TIME_WAIT: 收到了对方FIN报文,并发送出了ACK报文,等待2MSL后即可回到CLOSED状态了。
  注意:在FIN_WAIT_1状态下,如果收到了对方同时带FIN和ACK标志的报文(复用一个报文)时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方)
  CLOSING(比较少见): 如果双方几乎同时试图断开一个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,即会出现CLOSING状态,表示双方都试图关闭SOCKET连接。
  CLOSE_WAIT: 等待关闭连接,当对方发送FIN报文,回应ACK报文给对方后,则进入到CLOSE_WAIT状态。如果此时没有数据发送给对方,就可以关闭这个SOCKET,发送FIN报文给对方,即关闭连接。(被动方)
  LAST_ACK: 被动关闭方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,进入到CLOSED状态。(被动方)
  CLOSED: 连接中断。

Socket状态变化
  
    

参考:
https://zh.wikipedia.org/wiki/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE
http://www.kuqin.com/shuoit/20141018/342719.html
http://hackerxu.com/2014/11/16/TCP.html
https://www.centos.bz/2012/08/tcp-establish-close/
http://blog.csdn.net/xifeijian/article/details/12777187
http://www.cnblogs.com/skynet/archive/2010/12/12/1903949.html
http://blog.163.com/xychenbaihu@yeah/blog/static/13222965520118139252103/
https://commons.wikimedia.org/wiki/File:Tcp_close.svg

发布了89 篇原创文章 · 获赞 9 · 访问量 10万+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章