tcp/ip三次握手四次分手，撒手。。。。

2019独角兽企业重金招聘Python工程师标准>>>

‍

TCP/IP协议三次握手与四次撒手流程解析

•  

  一、TCP报文格式
    TCP/IP协议的详细信息参看《TCP/IP协议详解》三卷本。下面是TCP报文格式图：
  
  图1 TCP报文格式
    上图中有几个字段需要重点介绍下：
    （1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
    （2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
    （3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
    （A）URG：紧急指针（urgent pointer）有效。
    （B）ACK：确认序号有效。
    （C）PSH：接收方应该尽快将这个报文交给应用层。
    （D）RST：重置连接。
    （E）SYN：发起一个新连接。
    （F）FIN：释放一个连接。
  
   需要注意的是：
    （A）不要将确认序号Ack与标志位中的ACK搞混了。
    （B）确认方Ack=发起方Req+1，两端配对。 
  
  二、三次握手
    所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：
  
  图2 TCP三次握手
    （1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
    （2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为 1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
    （3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发 送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入 ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
   
    SYN攻击：
    在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是 Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址 是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网 络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
    #netstat -nap | grep SYN_RECV
  
  三、四次挥手
   三次握手耳熟能详，四次挥手估计就，所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：
  
  图3 TCP四次挥手
    由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个 FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的 一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
   （1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
    （2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
   （3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
    （4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
    上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图：

  
  图4 同时挥手
    流程和状态在上图中已经很明了了，在此不再赘述，可以参考前面的四次挥手解析步骤。
  
  四、附注
    关于三次握手与四次挥手通常都会有典型的面试题，在此提出供有需求的XDJM们参考：
    （1）三次握手是什么或者流程？四次握手呢？答案前面分析就是。
    （2）为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
    这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再 发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

上面这都是书上的死话看的人真恶心。。。

来通俗点的

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认； 
第 二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进 入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据.

四次分手：

 

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。

（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

个人的简单理解

3次握手：1.客户端发个请求“我要和你连接”到服务端

2.服务端发个“确认允许你连接+我要和你连接”到客户端

3.客户端蛋疼的再发个“我收到了你的允许了”到服务端

ok建立连接

四次撒手

1：客户端说：我要关了，给服务器，然后自己在那等消息。client-close-wait

2.服务器听到了，然后说，“我知道了”给客户端，也在等--server-close-wait

3.服务器关了连接，发个，我关了，给客户端，等客户端“说我知道了” --server-close-wait-ack

4.客户端发个我知道了，之后自己就关了

后期学习过程会遇到很多深入的问题，比如我们发现本机有很多Time wait状态，那个就是四次分手最后一步的状态，在这个状态下的端口是不可新建连接的

我们需要明白为什么需要timewait这个状态：

原因如下：

1.可靠实现TCP全双工连接终止，这个状态下才会发送我们的确认关闭信息，要不server端还会继续发送Fin

2.TCP分节可能会因为路由器异常然后“迷途：， 这个时候有可能tcp发送端确认超时而重发分节，但是迷途的分节在修复后也会发送到最终目的地，此时前一个tcp连接完成后，他已经正确完成了，而迷途的才到达，他会继续新建一个ip端口相同的tcp连接把迷途的分节传过去。。这是然并卵。。。 所以为了避免这种情况timewait组织在短时间内再次新建连接。

就这样了我是这样理解的，其实很简单的东西就被专业术语复杂化了，如果少了那么多晦涩难懂的专业术语我相信人类至少进步500年 。--by   无可奈何  当然官方术语有他的好处需要检查调整的时候那些seq ack是很重要的所以还是要多看看。

TCP滑动窗口机制

(2013-10-23 12:01:36)

转载▼

标签： tcp 三次握手 滑动窗口

分类：TCP/IP.OS

我们可以大概看一下上图的模型：

1. 首先是AB之间三次握手建立TCP连接。在报文的交互过程中，A将自己的缓冲区大小（窗口大小）3发送给B，B同理，这样双方就知道了对端的窗口大小。

2. A开始发送数据，A连续发送3个单位的数据，因为他知道B的缓冲区大小。在这一波数据发送完后，A就不能再发了，需等待B的确认。

3. A发送过来的数据逐渐将缓冲区填满。

4. 这时候缓冲区中的一个报文被进程读取，缓冲区有了一个空位，于是B向A发送一个ACK，这个报文中指示窗口大小为1。
   A收到B发过来的ACK消息，并且知道B将窗口大小调整为1，因此他只发送了一个单位的数据并且等待B的下一个确认报文。

5. 如此反复。

    

转载于:https://my.oschina.net/loveleaf/blog/480318