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

‍

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

•  

  1、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，两端配对。 
  
  2、三次握手
    所谓三次握手（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
  
  3、四次挥手
   三次握手耳熟能详，四次挥手估计就，所谓四次挥手（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 同时挥手
    流程和状态在上图中已经很明了了，在此再也不赘述，能够参考前面的四次挥手解析步骤。
  
  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. 如此反复。