为什么需要“三次握手”?

  为了解决“网络中存在延迟的重复分组”的问题,即为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。
  例:“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”。主要目的防止server端一直等待,浪费资源。

为什么需要“四次挥手”?
      那可能有人会有疑问,在tcp连接握手时为何ACK是和SYN一起发送,这里ACK却没有和FIN一起发送呢。原因是因为tcp是全双工模式接收到FIN时意味将没有数据再发来,但是还是可以继续发送数据。

TCP的状态转移图说到底就是一个状态机的不同状态之间的转换关系以及触发这些状态需要的条件,一共存在11个状态:

建立连接:

1.CLOSED:起始点,在超时或者连接关闭时候进入此状态。

2.LISTEN:server端在等待连接过来时候的状态,server端为此要调用socket, bind, listen函数,就能进入此状态。此称为应用程序被动打开(等待客户端来连接)。

3.SYN_SENT:客户端发起连接,发送SYN给服务器端。如果服务器端不能连接,则直接进入CLOSED状态。

4.SYN_RCVD:跟3对应,服务器端接受客户端的SYN请求,服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK,同时发送一个SYN给客户端;另外一种情况,客户端在发起SYN的同时接收到服务器端的SYN请求,客户端就会由SYN_SENT到SYN_RCVD状态。

5.ESTABLISHED:服务器端和客户端在完成3次握手进入状态,说明已经可以开始传输数据了。

连接关闭时候:关闭需要进行4次双方的交互,还包括要处理一些善后工作(TIME_WAIT状态)。

注意,这里主动关闭的一方或被动关闭的一方不是指特指服务器端或者客户端,是相对于谁先发起关闭请求来说的:

6.FIN_WAIT_1:主动关闭的一方,由状态5进入此状态。具体的动作时发送FIN给对方。

7.FIN_WAIT_2:主动关闭的一方,接收到对方的FIN ACK,进入此状态。由此不能再接收对方的数据。但是能够向对方发送数据。

8.CLOSE_WAIT:接收到FIN以后,被动关闭的一方进入此状态。具体动作时接收到FIN,同时发送ACK。

9.LAST_ACK:被动关闭的一方,发起关闭请求,由状态8进入此状态。具体动作时发送FIN给对方,同时在接收到ACK时进入CLOSED状态。

10.CLOSING:两边同时发起关闭请求时,会由FIN_WAIT_1进入此状态。具体动作是,接收到FIN请求,同时响应一个ACK。

11.TIME_WAIT:最纠结的状态来了。从状态图上可以看出,有3个状态可以转化成它,我们一一来分析:

a.由FIN_WAIT_2进入此状态:在双方不同时发起FIN的情况下,主动关闭的一方在完成自身发起的关闭请求后,接收到被动关闭一方的FIN后进入的状态。

b.由CLOSING状态进入:双方同时发起关闭,都做了发起FIN的请求,同时接收到了FIN并做了ACK的情况下,由CLOSING状态进入。

c.由FIN_WAIT_1状态进入:同时接受到FIN(对方发起),ACK(本身发起的FIN回应),与b的区别在于本身发起的FIN回应的ACK先于对方的FIN请求到达,而b是FIN先到达。这种情况概率最小。

关闭的4次连接最难理解的状态是TIME_WAIT,存在TIME_WAIT的2个理由:

1.可靠地实现TCP全双工连接的终止。

2.允许老的重复分节在网络中消逝。

特殊情况:

1. 同时打开

两个应用程序同时执行主动打开的情况是可能的,虽然发生的可能性较低。每一端都发送一个SYN,并传递给对方,且每一端都使用对端所知的端口作为本地端口。例如:

主机a中一应用程序使用7777作为本地端口,并连接到主机b 8888端口做主动打开。

主机b中一应用程序使用8888作为本地端口,并连接到主机a 7777端口做主动打开。

tcp协议在遇到这种情况时,只会打开一条连接。

这个连接的建立过程需要4次数据交换,而一个典型的连接建立只需要3次交换(即3次握手)

但多数伯克利版的tcp/ip实现并不支持同时打开。

SYN_RCVD与SYN_SEND都是转换为ESTABLISHED的中间状态,目标是两端均转换到ESTABLISHED状态。

2. 同时关闭

如果应用程序同时发送FIN,则在发送后会首先进入FIN_WAIT_1状态。在收到对端的FIN后,回复一个ACK,会进入CLOSING状态。在收到对端的ACK后,进入TIME_WAIT状态。这种情况称为同时关闭。

同时关闭也需要有4次报文交换,与典型的关闭相同。

TCP报文格式

每个字段的信息说明如下:

    • Source Port和Destination Port:分别占用16位,表示源端口号和目的端口号;用于区别主机中的不同进程,而IP地址是用来区分不同的主机的,源端口号和目的端口号配合上IP首部中的源IP地址和目的IP地址就能唯一的确定一个TCP连接;
    • Sequence Number:用来标识从TCP发端向TCP收端发送的数据字节流,它表示在这个报文段中的的第一个数据字节在数据流中的序号;主要用来解决网络报乱序的问题;
    • Acknowledgment Number:32位确认序列号包含发送确认的一端所期望收到的下一个序号,因此,确认序号应当是上次已成功收到数据字节序号加1。不过,只有当标志位中的ACK标志(下面介绍)为1时该确认序列号的字段才有效。主要用来解决不丢包的问题;
    • Offset:给出首部中32 bit字的数目,需要这个值是因为任选字段的长度是可变的。这个字段占4bit(最多能表示15个32bit的的字,即4*15=60个字节的首部长度),因此TCP最多有60字节的首部。然而,没有任选字段,正常的长度是20字节;
    • TCP Flags:TCP首部中有6个标志比特,它们中的多个可同时被设置为1,主要是用于操控TCP的状态机的,依次为URGACKPSHRSTSYNFIN。每个标志位的意思如下:
      • URG:此标志表示TCP包的紧急指针域(后面马上就要说到)有效,用来保证TCP连接不被中断,并且督促中间层设备要尽快处理这些数据;
      • ACK:此标志表示应答域有效,就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值:0和1,为1的时候表示应答域有效,反之为0;
      • PSH:这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后,立即传送给应用程序,而不是在缓冲区中排队;
      • RST:这个标志表示连接复位请求。用来复位那些产生错误的连接,也被用来拒绝错误和非法的数据包;
      • SYN:表示同步序号,用来建立连接。SYN标志位和ACK标志位搭配使用,当连接请求的时候,SYN=1,ACK=0;连接被响应的时候,SYN=1,ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包,如果对方主机响应了一个数据包回来 ,就表明这台主机存在这个端口;但是由于这种扫描方式只是进行TCP三次握手的第一次握手,因此这种扫描的成功表示被扫描的机器不很安全,一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手;
      • FIN: 表示发送端已经达到数据末尾,也就是说双方的数据传送完成,没有数据可以传送了,发送FIN标志位的TCP数据包后,连接将被断开。这个标志的数据包也经常被用于进行端口扫描。
    • Window:窗口大小,也就是有名的滑动窗口,用来进行流量控制;这是一个复杂的问题,这篇博文中并不会进行总结的;

TCP握手及状态图的更多相关文章

  1. HTTPS工作原理和TCP握手机制

    1.HTTPS的工作原理 HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手, 在握手过程中将确立双方加密传输数据的密码信息. TLS/SSL协议不仅仅是一套加密传输的协议, ...

  2. 抓包分析 TCP 握手和挥手

    前言 首先需要明确的是 TCP 是一个可靠传输协议,它的所有特点最终都是为了这个可靠传输服务.在网上看到过很多文章讲 TCP 连接的三次握手和断开连接的四次挥手,但是都太过于理论,看完感觉总是似懂非懂 ...

  3. TCP 握手和挥手图解(有限状态机)

    1.引言 TCP 这段看过好几遍,老是记不住,没办法找工作涉及到网络编程这块,各种问 TCP .今天好好整理一下握手和挥手过程.献给跟我一样忙碌,找工作的童鞋,欢迎大神批评指正. 2.TCP 的连接建 ...

  4. 网络之TCP握手总结

    目录: 31.Tcp握手的一些问题? 21.Tcp三次握手及SYN攻击: 四次握手? 为什么建立连接是三次握手,而关闭连接却是四次挥手? 13.TCP释放连接四次握手 12.TCP建立连接三次握手 1 ...

  5. TCP握手协议简述

    TCP握手协议简述在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器 ...

  6. TCP握手

    1.TCP的三次握手四次挥手 第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认. 第二 ...

  7. 通俗理解TCP握手次数是三次

    理解之后,应该说是至少三次就可以保证可靠传输了. 看到网上一篇帖子http://www.cnblogs.com/TechZi/archive/2011/10/18/2216751.html是这么说的, ...

  8. 滴滴工程师带你深入理解 TCP 握手分手全过程

      本文作者:饶全成,中科院计算所硕士,滴滴出行后端研发工程师. 个人主页:https://zhihu.com/people/raoquancheng   记得刚毕业找工作面试的时候,经常会被问到:你 ...

  9. TCP握手过程中建连接的流程和队列

    这里有两个队列:syns queue(半连接队列):accept queue(全连接队列). 三次握手过程中: 第一步: server 收到 client 的 syn 后,把这个连接信息放到半连接队列 ...

随机推荐

  1. webView返回不刷新

    [[NSUserDefaults standardUserDefaults] setInteger:2 forKey: @"WebKitCacheModelPreferenceKey&quo ...

  2. python基础之练习题(二)

    九九乘法表 i = 0 #while 九九乘法表 j = 0 while i < 9: i += 1 while j<9: j += 1 sum = i + j total="% ...

  3. django的framework优化

    1.优化framework的性能,解决restapi调用慢的问题 ①预加载,关联查询时做缓存,序列化前简单调用setup_eager_loading ,这个需要确定sql查询调用情况(根据数据库结构确 ...

  4. 洛谷P4799 世界冰球锦标赛 CEOI2015 Day2 meet-in-the-middle

    正解:折半搜索 解题报告: 先放个传送门QAQ 想先说下部分分?因为包含了搜索背包两个方面就觉得顺便复习下?QwQ 第一档部分分 爆搜 就最最普通的爆搜鸭,dfs(第几场,钱),然后每次可以看可以不看 ...

  5. 人人网张铁安:Feed系统架构分析(转)

    原文:http://www.csdn.net/article/2010-07-26/277273 继成功举办首期TUP活动后,日前在北京丽亭华苑酒店鸿运二厅,由CSDN和<程序员> 杂志联 ...

  6. git-【三】理解工作区与暂存区的区别

    基本概念 工作区:就是你在电脑上看到的目录,比如目录下testgit里的文件(.git隐藏目录版本库除外).或者以后需要再新建的目录文件等等都属于工作区范畴.       版本库(Repository ...

  7. [3D]1.绘制三角形

    作为一个.Net程序员学习3D开发好尴尬啊,因为不论是OpenGL还是Direct3D都是用C/C++开发的比较多.虽然有计划使用C++进行开发,但是平时还是C#使用的多.很少用C++做东西,如果仅仅 ...

  8. Django REST framework 之 API认证

    RESTful API 认证 和 Web 应用不同,RESTful APIs 通常是无状态的, 也就意味着不应使用 sessions 或 cookies, 因此每个请求应附带某种授权凭证,因为用户授权 ...

  9. glassfish3新建domain

    下载路径:http://download.oracle.com/glassfish/3.1.2.2/release/index.html .zip (解压缩)cd /glassfish3/glassf ...

  10. [转]AJAX 跨源 HTTP 请求

    转自OSChina, 原文: http://www.oschina.net/translate/ajax-cross-origin-http-request 背景 跨源HTTP请求(也称跨域AJAX请 ...