精华内容
下载资源
问答
  • TCP三次握手详解-深入浅出(有图实例演示)

    万次阅读 多人点赞 2018-08-08 21:13:48
    TCP三次握手 TCP三次握手简单如下图: TCP三次握手的过程描述: 1.客户主动(active open)去connect服务器,并且发送SYN 假设序列号为J, 服务器是被动打开(passive open) 2.服务器在收到SYN后,它...

    1. 准备

    TCP是属于网络分层中的传输层,因为OSI分为7层,感觉太麻烦了,所以分为四层就好了,简单。
    分层以及每层的协议,TCP是属于传输层,如下两张图:
    图1
    这里写图片描述

    TCP三次握手会涉及到状态转换所以这里贴出TCP的状态转换图如下:
    这里写图片描述

    2.TCP三次握手简述

    要想简单了解TCP三次握手,我们首先要了解TCP头部结构,如下:
    在这里插入图片描述

    TCP传递给IP层的信息单位称为报文段或段,下面都用做单位。

    TCP三次握手如图:
    这里写图片描述

    2.1 第一次握手

    客户端给服务器发送一个SYN段(在 TCP 标头中 SYN 位字段为 1 的 TCP/IP 数据包), 该段中也包含客户端的初始序列号(Sequence number = J)。

    SYN是同步的缩写,SYN 段是发送到另一台计算机的 TCP 数据包,请求在它们之间建立连接

    2.2 第二次握手

    服务器返回客户端 SYN +ACK 段(在 TCP 标头中SYN和ACK位字段都为 1 的 TCP/IP 数据包), 该段中包含服务器的初始序列号(Sequence number = K);同时使 Acknowledgment number = J + 1来表示确认已收到客户端的 SYN段(Sequence number = J)。

    ACK 是“确认”的缩写。 ACK 数据包是任何确认收到一条消息或一系列数据包的 TCP 数据包

    2.3 第三次握手

    客户端给服务器响应一个ACK段(在 TCP 标头中 ACK 位字段为 1 的 TCP/IP 数据包), 该段中使 Acknowledgment number = K + 1来表示确认已收到服务器的 SYN段(Sequence number = K)。

    2.4 实例观察

    2.4.1 tcpdump

    使用tcpdump观察如下:因为都是在本机同时运行client和server所以命令为:tcpdump -i lo port 5555, 只能监听回路lo接口,结果如下
    这里写图片描述
    如图用红色圈起来的就是3次握手,但是为什么最后一次握手,为什么ack = 1,而不是369535922 呢,
    这是因为这里的第三次握手tcpdump显示的是相对的顺序号。但是为了便于观察我们需要把tcpdump的
    顺序号变为绝对的顺序号。

    命令只需要加-S(大写)便可,即:tcpdump -i lo port 5555 -S
    加上之后结果就正常了如下图:
    这里写图片描述
    从tcpdump的数据,可以明显的看到三次握手的过程是:
    第一次握手:client SYN=1, Sequence number=2322326583 —> server
    第二次握手:server SYN=1,Sequence number=3573692787; ACK=1, Acknowledgment number=2322326583 + 1 —> client
    第三次握手:client ACK=1, Acknowledgment number=3573692787 + 1 -->server

    3.TCP三次握手详细解析过程:

    这里写图片描述

    3.1 第一次握手

    客户在socket() connect()后主动(active open)连接上服务器, 发送SYN ,这时客户端的状态是SYN_SENT
    服务器在进行socket(),bind(),listen()后等待客户的连接,收到客户端的 SYN 后,

    3.1.1 半连接队列(syn queue)未满

    服务器将该连接的状态变为SYN_RCVD, 服务器把连接信息放到半连接队列(syn queue)里面。

    3.1.2 半连接队列(syn queue)已满

    服务器不会将该连接的状态变为SYN_RCVD,且将该连接丢弃(SYN flood攻击就是利用这个原理,
    对于SYN foold攻击,应对方法之一是使syncookies生效,将其值置1即可,路径/proc/sys/net/ipv4/tcp_syncookies,
    即使是半连接队列syn queue已经满了,也可以接收正常的非恶意攻击的客户端的请求,
    但是这种方法只在无计可施的情况下使用,man tcp里面的解析是这样说的,
    这里写图片描述
    但是我不知道为什么Centos6.9默认是置为1,所以这让我很疑惑
    这里写图片描述)。
    半连接队列(syn queue)最大值 /proc/sys/net/ipv4/tcp_max_syn_backlog
    这里写图片描述
    SYN flood攻击

    攻击方的客户端只发送SYN分节给服务器,然后对服务器发回来的SYN+ACK什么也不做,直接忽略掉,
    不发送ACK给服务器;这样就可以占据着服务器的半连接队列的资源,导致正常的客户端连接无法连接上服务器。-----[维基百科]

    (SYN flood攻击的方式其实也分两种,第一种,攻击方的客户端一直发送SYN,对于服务器回应的SYN+ACK什么也不做,不回应ACK, 第二种,攻击方的客户端发送SYN时,将源IP改为一个虚假的IP, 然后服务器将SYN+ACK发送到虚假的IP, 这样当然永远也得不到ACK的回应。)

    3.2 第二次握手

    服务器返回SYN+ACK段给到客户端,客户端收到SYN+ACK段后,客户端的状态从SYN_SENT变为ESTABLISHED,
    也即是connect()函数的返回。

    3.3 第三次握手

    全连接队列(accept queue)的最大值 /proc/sys/net/core/somaxconn (默认128)
    这里写图片描述
    全连接队列值 = min(backlog, somaxconn)
    这里的backlog是listen(int sockfd, int backlog)函数里面的那个参数backlog

    3.3.1 全连接队列(accept queue)未满

    服务器收到客户端发来的ACK, 服务端该连接的状态从SYN_RCVD变为ESTABLISHED,
    然后服务器将该连接从半连接队列(syn queue)里面移除,且将该连接的信息放到全连接队列(accept queue)里面。

    3.3.2 全连接队列(accept queue)已满

    服务器收到客户端发来的ACK, 不会将该连接的状态从SYN_RCVD变为ESTABLISHED。
    当然全连接队列(accept queue)已满时,则根据 tcp_abort_on_overflow 的值来执行相应动作
    /proc/sys/net/ipv4/tcp_abort_on_overflow 查看参数值
    这里写图片描述

    3.3.2.1 tcp_abort_on_overflow = 0

    则服务器建立该连接的定时器,

    这个定时器是一个服务器的规则是从新发送syn+ack的时间间隔成倍的增加,
    比如从新了第二次握手,进行了5次,这五次的时间分别是 1s, 2s,4s,8s,16s,
    这种倍数规则叫“二进制指数退让”(binary exponential backoff)

    给客户端定时从新发回SYN+ACK即从新进行第二次握手,(如果客户端设定的超时时间比较短就很容易出现异常)
    服务器从新进行第二次握手的次数/proc/sys/net/ipv4/tcp_synack_retries
    这里写图片描述

    3.3.2.2 tcp_abort_on_overflow = 1

    关于tcp_abort_on_overflow的解析如下:
    这里写图片描述
    意思应该是,当 tcp_abort_on_overflow 等于1 时,重置连接(一般是发送RST给客户端),
    至于怎么重置连接是系统的事情了。
    不过我在查资料的过程发现,阿里中间件团队博客说并不是发送RST, —[阿里中间件团队博客]

    这个博客跑的实例观察到的是服务器会忽略client传过来的包,然后client重传,一定次数后client认为异常,然后断开连接。
    当然,我们写代码的都知道代码是第一手的注释,实践是检验真理的唯一标准
    最好还是自己以自己实践为准,因为可能你的环境跟别人的不一样。)

    查看全连接队列(accept queue)的使用情况
    这里写图片描述
    如上图,第二列Recv-Q是,全连接队列接收到达的连接,第三列是Send-Q全连接队列的所能容纳最大值,
    如果,Recv-Q 大于 Send-Q 那么大于的那部分,是要溢出的即要被丢弃overflow掉的。

    希望热心的网友帮忙提改进意见时可以直接指出哪一段第几句(比如 2.4.1 tcpdump 第一段第一句, 命令tcpdump -i lo port 5555 里参数 i 用错了,应该用 I),这样比较快速找到好改正。

    感想:
    1.本来想写TCP连接的建立和终止的,没想到要讲清楚TCP连接的建立已经很大的篇幅了,就只讲TCP连接的建立而已。
    2.以前看书的时候,没有解决一个问题的来的深刻或者说脉络清晰,这个就是主题阅读的好处吧。
    3.以前没有养成一个遇到问题深入解析,解决问题的习惯,今后慢慢养成。

    下面的参考1有实例,会比较详细一点,清晰一些。
    参考:

    1. http://jm.taobao.org/2017/05/25/525-1/
    2. https://coolshell.cn/articles/11564.html
    3. https://zh.wikipedia.org/wiki/SYN_cookie
    4. https://zh.wikipedia.org/wiki/SYN_flood
    5. https://www.cnblogs.com/menghuanbiao/p/5212131.html
    展开全文
  • 动画:用动画给面试官解释 TCP 三次握手过程

    万次阅读 多人点赞 2019-10-12 07:55:38
    TCP 三次握手过程对于面试是必考的一个,所以不但要掌握 TCP 整个握手的过程,其中有些小细节也更受到面试官的青睐。 对于这部分掌握以及 TCP 的四次挥手,小鹿将会以动画的形式呈现给每个人,这样将复杂的知识简单...

    在这里插入图片描述
    作者 | 小鹿
    来源 | 公众号:小鹿动画学编程


    写在前边

    TCP 三次握手过程对于面试是必考的一个,所以不但要掌握 TCP 整个握手的过程,其中有些小细节也更受到面试官的青睐。

    对于这部分掌握以及 TCP 的四次挥手,小鹿将会以动画的形式呈现给每个人,这样将复杂的知识简单化,理解起来也容易了很多,尤其对于一个初学者来说。


    学习导图

    在这里插入图片描述

    一、TCP 是什么?

    TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。

    我们知道了上述了解到了 TCP 的定义,通俗一点的讲,TCP 就是一个双方通信的一个规范标准(协议)。

    我们在学习 TCP 握手过程之前,首先必须了解 TCP 报文头部的一些标志信息,因为在 TCP 握手的过程中,会使用到这些报文信息,如果没有掌握这些信息,在学习握手过程中,整个人处于懵逼状态,也是为了能够深入 TCP 三次握手的原理。


    二、TCP 头部报文

    在这里插入图片描述

    2.1 source portdestination port

    两者分别为「源端口号」和「目的端口号」。源端口号就是指本地端口,目的端口就是远程端口。

    一个数据包(pocket)被解封装成数据段(segment)后就会涉及到连接上层协议的端口问题。

    可以这么理解,我们可以想象发送方很多的窗户,接收方也有很多的窗户,这些窗口都标有不同的端口号,源端口号和目的端口号就分别代表从哪个规定的串口发送到对方接收的窗口。不同的应用程度都有着不同的端口,之前网络分层的文章中有提到过。
    在这里插入图片描述

    扩展:应用程序的端口号和应用程序所在主机的 IP 地址统称为 socket(套接字),IP:端口号, 在互联网上 socket 唯一标识每一个应用程序,源端口+源IP+目的端口+目的IP称为”套接字对“,一对套接字就是一个连接,一个客户端与服务器之间的连接。


    2.2 Sequence Numbe

    称为「序列号」。用于 TCP 通信过程中某一传输方向上字节流的每个字节的编号,为了确保数据通信的有序性,避免网络中乱序的问题。接收端根据这个编号进行确认,保证分割的数据段在原始数据包的位置。

    在这里插入图片描述
    再通俗一点的讲,每个字段在传送中用序列号来标记自己位置的,而这个字段就是用来完成双方传输中确保字段原始位置是按照传输顺序的。(发送方是数据是怎样一个顺序,到了接受方也要确保是这个顺序)

    PS:初始序列号由自己定,而后绪的序列号由对端的 ACK 决定:SN_x = ACK_y (x 的序列号 = y 发给 x 的 ACK),这里后边会讲到。


    2.3 Acknowledgment Numbe

    称为「确认序列号」。确认序列号是接收确认端所期望收到的下一序列号。确认序号应当是上次已成功收到数据字节序号加1,只有当标志位中的 ACK 标志为 1 时该确认序列号的字段才有效。主要用来解决不丢包的问题。

    若确认号=N,则表明:到序号N-1为止的所有数据都已正确收到。

    在这里,现在我们只需知道它的作用是什么,就是在数据传输的时候是一段一段的,都是由序列号进行标识的,所以说,接收端每接收一段,之后就想要的下一段的序列号就称为「确认序列号」。


    2.4 TCP Flag

    TCP 首部中有 6 个标志比特,它们中的多个可同时被设置为 1,主要是用于操控 TCP 的状态机的,依次为URG,ACK,PSH,RST,SYN,FIN

    不要求初学者全部掌握,在这里只讲三个重点的标志:


    2.4.1 ACK

    这个标识可以理解为发送端发送数据到接收端,发送的时候 ACK 为 0,标识接收端还未应答,一旦接收端接收数据之后,就将 ACK 置为 1,发送端接收到之后,就知道了接收端已经接收了数据。
    在这里插入图片描述

    此标志表示「应答域有效」,就是说前面所说的TCP应答号将会包含在 TCP 数据包中;有两个取值:0 和 1,为 1 的时候表示应答域有效,反之为 0;


    2.4.2 SYN

    表示「同步序列号」,是 TCP 握手的发送的第一个数据包。

    用来建立 TCP 的连接。SYN 标志位和 ACK 标志位搭配使用,当连接请求的时候,SYN=1,ACK=0连接被响应的时候,SYN=1,ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有 SYN 的数据包,如果对方主机响应了一个数据包回来 ,就表明这台主机存在这个端口。看下面动画:
    在这里插入图片描述

    2.4.3 FIN

    表示发送端已经达到数据末尾,也就是说双方的数据传送完成,没有数据可以传送了,发送FIN标志位的 TCP 数据包后,连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

    这个很好理解,就是说,发送端只剩最后的一段数据了,同时要告诉接收端后边没有数据可以接受了,所以用FIN标识一下,接收端看到这个FIN之后,哦!这是接受的最后的数据,接受完就关闭了。动画如下:
    在这里插入图片描述

    2.5 Window size

    称为滑动窗口大小。所说的滑动窗口,用来进行流量控制。


    3、为什么进行 TCP 三次握手?

    如果之前你不了解网络分层的话,建议看看写的文章。

    你真的懂网络分层协议吗?

    第一,为了确认双方的接收与发送能力是否正常。第二,指定自己的初始化序列号,为后面的可靠传送做准备。第三,如果是 https 协议的话,三次握手这个过程,还会进行数字证书的验证以及加密密钥的生成到。

    如果你了解 UDP 的话,TCP 的出现正式弥补了 UDP 不可靠传输的缺点。但是 TCP 的诞生,也必然增加了连接的复杂性。


    4、TCP 三次握手过程?

    TCP 三次握手的过程掌握最重要的两点就是客户端和服务端状态的变化,另一个是三次握手过程标志信息的变化,那么掌握 TCP 的三次握手就简单多了。下面我们就以动画形式进行拆解三次握手过程。
    在这里插入图片描述

    • 初始状态:客户端处于 closed(关闭)状态,服务器处于 listen(监听) 状态。
      在这里插入图片描述
    • 第一次握手:客户端发送请求报文将 SYN = 1同步序列号和初始化序列号seq = x发送给服务端,发送完之后客户端处于SYN_Send状态。

    在这里插入图片描述

    • 第二次握手:服务端受到 SYN 请求报文之后,如果同意连接,会以自己的同步序列号SYN(服务端) = 1、初始化序列号 seq = y和确认序列号(期望下次收到的数据包)ack = x+ 1 以及确认号ACK = 1报文作为应答,服务器为SYN_Receive状态。

    在这里插入图片描述

    • 第三次握手: 客户端接收到服务端的 SYN + ACK之后,知道可以下次可以发送了下一序列的数据包了,然后发送同步序列号 ack = y + 1和数据包的序列号 seq = x + 1以及确认号ACK = 1确认包作为应答,客户端转为established状态。

    在这里插入图片描述

    5、为什么不是一次、二次握手?

    防止了服务器端的一直等待而浪费资源。

    为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。如果此时客户端发送的延迟的握手信息服务器收到,然后服务器进行响应,认为客户端要和它建立连接,此时客户端并没有这个意思,但 server 却以为新的运输连接已经建立,并一直等待 client 发来数据。这样,server 的很多资源就白白浪费掉了。


    ----------------------------------------------------------------------- 于2019/11/11 修改 ------------------------------------------------------------------
    主要对文章中存在的笔误和错误进行了修改,动画也进行了重新制作和修改,文章内容也进行的部分内容增加 —— 三次握手过程详细细节部分。再次感谢大家对小鹿文章的支持!

    下一篇:动画:用动画给女朋友讲解 TCP 四次分手过程


    福利:可以在我的公众号『小鹿动画学编程』,后台回复『资源』即可获取。

    ❤️ 不要忘记留下你学习的脚印 [点赞 + 收藏 + 评论]

    一些后台小伙伴问我平常如何学习的,学习资料哪里获取,我就不一一回复了!一般我都是通过看一些编程书籍和开源的社区进行自学,一些学习资料和电子书也分享到下边了,有需要的自取。

    编程在于永无止境的去学习,去学习前辈积累的经验,书籍就是最好的一种媒介方式,列出以下自己看过的优秀书籍,整理成了 PDF 版。

    • 前端:《javascript高级程序设计》《JavaScript 权威指南》《你不知道的JavaScript(上中下卷)》等;
    • java:《Effective Java》《Thinking in Java》《Java 编程思想》《java核心技术》等;
    • 算法:《大话数据结构》《算法图解》《算法导论》《编程之美》《数据结构与算法:C语言描述》等;
    • 其他相关计算机书籍;

    搜索我的公众号:「小鹿动画学编程」后台回复关键词

    • 回复「后台」,获取 java 等自学资料
    • 回复「前端」,获取前端等自学资料
    • 回复「电子书」获取一下书籍资料!

    动一动你的小手,点赞就完事了,每个人出一份力量(点赞 + 评论)就会让更多的学习者加入进来!非常感谢! ̄ω ̄=


    作者Info:

    【作者】:小鹿

    【原创公众号】:小鹿动画学编程。

    【简介】:和小鹿同学一起用动画的方式从零基础学编程,将 Web前端领域、数据结构与算法、网络原理等通俗易懂的呈献给小伙伴。先定个小目标,原创 1000 篇的动画技术文章,和各位小伙伴共同努力一起学习!公众号回复 “资料” 送一从零自学资料大礼包!

    【转载说明】:转载请说明出处,谢谢合作!~

    展开全文
  • TCP三次握手

    2013-01-06 09:04:43
    TCP三次握手,TCP三次握手是TCP连接建立过程的可靠性保证
  • TCP三次握手原理

    万次阅读 多人点赞 2019-10-22 09:06:54
    TCP协议\TCP三次握手

    在众多的网络协议中,TCP协议占据着举足轻重的地位,你知道什么是TCP协议吗?

    一、TCP协议

    TCP(Transmission Control Protoco)协议属于计算机网络体系中的运输层。运输层的任务是负责向主机中应用层进程之间的通信提供通用的数据传输服务。所以可以通俗理解TCP协议就是进程间数据通讯传输协议。根据不同应用,运输层主要使用TCP和UDP两种协议之一。如果想要了解计算机网络体系分层概念,可以看我的上一篇博文 计算机网络体系结构划分
    计算机网络体系结构

    二、TCP协议特点

    TCP协议本身是比较复杂的,它包含拥塞控制、可靠传输、流量控制、连接管理等功能,主要特点包含以下几个方面:

    • TCP是面向连接的协议,程序在使用TCP协议通讯时,必须要先建立TCP连接。这就好比我要给你打电话,咱俩之间的通讯线路必须是连接状态的。
    • TCP连接是点对点的,每一条TCP连接只能有两个端口(endpoint)。这个端点就是我们Java网络编程所使用的套接字(socket)。由IP地址+端口号组成(IP:端口号)。
    • TCP连接提供可靠交付,使用TCP连接传输数据,保证无差错、不丢失、不重复并且按顺序到达
    • TCP连接是双向的通信,通信的两方,既能发送数据,也能接收数据。就向我们通话时双方一样。
    • TCP面向字节流传输数据,TCP传送数据时,是把进程交付的数据,按照一段段字节流序列传递的,每次传输其中一段字节序列。应用层接收字节序列后,再将内容还原。

    三、TCP报文格式

    既然TCP协议属于运输层,运输层职责是为主机应用层提供进程间的数据传输,所以我们有必要搞清楚TCP协议运输数据时的形式。TCP协议规定了TCP传输数据的单元为TCP数据报。TCP数据报是对应用层进程交付数据的封装。
    TCP数据报由两部分组成:TCP首部TCP数据部分

    • TCP首部:包含许多控制和描述字段,是TCP全部功能的体现
    • TCP数据部分:对于应用层进程交付的数据,封装后的字节流序列
      TCP报文格式
      应用层进程交付的数据被封装TCP报文,然后进行传输,TCP连接保证数据传输的可靠性,TCP报文传输的过程示意图:
      TCP数据传输模型

    四、TCP报文首部

    TCP报文首部定义是TCP协议的精华所在,TCP复杂功能的实现,全部依靠了首部里各种控制字段。我们来看下TCP首部都定义了什么:
    TCP报文首部
    TCP报文的首部由20个字节固定字节4n(n取[0~5]整数)个可变的选项字节组成,其中固定部分的各字段含义如下:

    • 源端口目的端口:各占2个字节,分别写入通信双方进程端口号

    • 序号seq:占4个字节。在TCP连接中,传送的字节流中的每一个字节都是要按顺序编号[0~232-1],整个要传送的字节流的起始序号在必须连接建立时设置,序号字段值代表本报文段所发送的数据的第一个字节的序号

    • 确认号ack:占4个字节,是期望收到对方的下一个报文段的第一个数据字节的序号,即ack=N,就代表了到序号N-1为止的所有数据都被正确接收了。

    • 数据偏移:占4位,表示TCP报文的数据部分起始处距离TCP报文首部的起始处有多远,数据偏移值的单位是32位字(以4字节为计算单位),4位二进制能表示的值[0~15],这就意味着TCP首部最大长度为60字节,也就是选项部分的最大长度为40字节。

    • 保留位:占6位,保留为以后使用,目前置为0

    • 控制位:占6位,每个控制字段占1位,它们的标识和含义是:
      - 紧急URG:URG=1时,告诉系统此报文中有紧急数据,优先传送,与紧急指针配合使用
      - 确认ACK:当ACK=1时,确认号才有效,ACK=0时,确认号无效,TCP连接建立后,所有报文ACK必须都为1
      - 推送PSH:发送方把PSH置为1,接收方收到报文后会尽快交付,不用等缓存填满了再交付
      - 复位RST:当RST=1时,表明TCP连接出现了严重差错,必须释放连接,然后重新建立新运输连接。RST=1还可以用来拒接一个非法报文段或拒绝打开一个连接。
      - 同步SYN:在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文段,对方若同意建立连接,则需要在响应报文中使SYN=1和ACK=1
      - 终止FIN:用来释放一个连接 。当FIN=1时,表明此报文段的发送方数据已经发送完毕,并且要求释放运输连接。

    • 窗口:占2字节,窗口值是[0~216-1]之间的整数。窗口值告诉了对方,从本报文段的确认号算起,允许对方发送的数据量。

    • 检验和:占2字节,用于接收方检验首部和数据部分是否在传输中有差错,类似我们下载文件时的Md5签名校验作用。

    • 紧急指针:占2字节,URG=1时才起作用,用于指明本报文段中的紧急数据的字节数,紧急数据结束后就是普通数据,所以紧急指针指出了紧急数据的末尾在报文中位置。

    • 选项:长度可变,最小0字节,最长达40字节。首部用来动态存储数据。

    五、三次握手过程

    TCP是面向连接的,所以每次传输数据之前,必须要建立TCP连接,在TCP建立连接时主要解决三个层面问题:

    • 使连接的每一方都能确认对方的存在
    • 协商连接中参数,比如各方窗口值,时间戳等
    • 各方对运输资源如缓存大小、连接表等进行分配

    我们都知道TCP连接采用的是C/S模式,主动发起连接的叫客户端client,被动等待连接的叫服务器Server。那么TCP建立连接的过程是什样的呢?什么是三次握手呢?
    在这里插入图片描述
    默认情况下客户端client和服务端sever的TCP进程都处于CLOSED(关闭)状态。
    服务端TCP服务进程先建立传输控制块TCB,然后服务端进入LISTEN状态,等待客户端连接请求。

    • 第一次握手:客户端TCP进程也先建立传输控制块TCB,然后向服务端发送连接请求报文段,此时SYN=1,随机选定一个初始序号seq=x,,此报文不能携带数据,但是要消耗掉一个序号,发送完毕后,客户端进入SYN-SENT(同步已发送)状态
    • 第二次握手:服务端收到客户端请求连接报文段后,若同意建立连接,则发送确认报文,确认报文中SYN=1、ACK=1,确认号ack=x+1,同时随机选定一个自己序号seq=y,确认报文段同样不能携带数据,但是也要消耗掉一个序号,发送完毕后服务端进入SYN-RCVD(同步收到)状态
    • 第三次握手:客户端收到确认报文后,检查ACK=1,ack=x+1是否正确,若正确,则向服务端发送确认报文,确认报文中ACK=1,ack=y+1,seq=x+1,发送后进入ESTAB-LISHED状态,服务端收到确认报文后,也进入ESTAB-LISHED状态,此时双方TCP连接正式建立。

    上面的连接建立过程就是TCP三次握手

    六、为什么是三次握手?

    为什么client收到确认报文后,还要再发送一次确认报文给server呢?这主要是为了防止已失效的连接请求报文段突然又送到了Server端。
    假设现在TCP连接是两次握手机制,如下图server在收到client的连接请求,确认后就进入ESTAB-LISHED状态,会存在这样一种问题:
    client发送连接请求报文,由于网络原因,长时间阻塞在某个网络节点上了,于是client重传了一次请求连接报文,第二次请求报文正常达到server,连接正常建立,数据传输完毕后,释放连接。但是假设此时第一次发送的请求报文并没有丢失,而是延误一段时间才到达server,这本是已失效的连接请求报文段,但是server收到后,会以为是client重新发送的连接请求,于是向client发送确认报文后,进入ESTAB-LISHED状态,但是client并没有发出新建连接的请求,就会忽略server的确认报文,server却在一直等待client发送数据,导致server资源浪费严重。
    两次握手
    总结起来看,TCP三次握手过程就是client与server在相互确认各自发送和接收是否正常的过程:

    • 第一次握手:client—>server,server确认了cilent的发送能力和自己的接收能力是正常的
    • 第二次握手:server—>client,client确认了自己的发送能力和server的接收能力是正常的,但是server此时不清楚自己的发送能力是否正常
    • 第三次握手:client—>server,server确认了自己的发送能力正常,同时也表明双方也都确认完毕,可以开始传输数据。

    那么为什么不进行四次握手呢?这个问题留给你们解答。

    展开全文
  • tcp三次握手

    2018-03-16 14:29:02
    主要理解三次握手的过程。针对长连接和短连接进行比较
  • 一、为什么握手三次,而不是两次或者四次? 答:两次不安全,四次没必要。tcp通信需要确保双方都具有数据收发的能力,因此双方都要发送SYN确保对方具有通信的能力 二、为什么挥手是四次而不是三次? 答:发送FIN包...

    TCP的定义

    TCP全称为Transmission Control Protocol(传输控制协议),是一种面向连接的可靠的基于字节流的传输层通信协议。TCP是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

    TCP的三次握手和四次挥手,可以说是老生常谈的经典问题了,通常也作为各大公司常见的面试考题,具有一定的水平区分度。看似简单的面试问题。如果你的回答不符合面试官期待的水准,有可能就直接凉凉了。

    本文会围绕,从三次握手和四次挥手相关的一系列核心问题,分享如何更准确回答和应对常见的面试问题,以后面对再刁钻的面试官,你都可以随意地跟他扯皮了
    在这里插入图片描述

    优雅回答三次握手

    三次握手服务端新建套接字,绑定地址信息后开始监听,进入LISTEN状态。客户端新建套接字绑定地址信息后调用connect,发送连接请求SYN,并进入SYN_SENT状态,等待服务器的确认。服务端一旦监听到连接请求,就会将连接放入内核等待队列中,并向客户端发送SYN和确认报文段ACK,进入SYN_RECD状态。客户端收到SYN+ACK报文后向服务端发送确认报文段ACK,并进入ESTABLISHED状态,开始读写数据。服务端一旦收到客户端的确认报文,就进入ESTABLISHED状态,就可以进行读写数据了
    在这里插入图片描述

    为什么握手是三次,而不是两次或者四次?

    两次不安全,四次没必要。tcp通信需要确保双方都具有数据收发的能力,得到ACK响应则认为对方具有数据收发的能力,因此双方都要发送SYN确保对方具有通信的能力。第一次握手是客户端发送SYN,服务端接收,服务端得出客户端的发送能力和服务端的接收能力都正常;第二次握手是服务端发送SYN+ACK,客户端接收,客户端得出客户端发送接收能力正常,服务端发送接收能力也都正常,但是此时服务器并不能确认客户端的接收能力是否正常;第三次握手客户端发送ACK,服务器接收,服务端才能得出客户端发送接收能力正常,服务端自己发送接收能力也都正常。

    三次握手可以携带数据吗?

    :第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。假设第一次可以携带数据,如果有人恶意攻击服务器,每次都在第一次握手中的SYN报文放入大量数据,重复发送大量SYN报文,此时服务器会花费大量内存空间来缓冲这些报文,服务器就更容易被攻击了

    tcp三次握手失败,服务端会如何处理?

    :握手失败的原因有两种,第一种是服务端没有收到SYN,则什么都不做;第二种是服务端回复了SYN+ACK后,长时间没有收到ACK响应,则超时后就会发送RST重置连接报文,释放资源

    ISN代表什么?意义何在?ISN是固定不变的吗?ISN为何要动态随机

    ISN全称是Initial Sequence Number,是TCP发送方的字节数据编号的原点,告诉对方我要开始发送数据的初始化序列号。ISN如果是固定的,攻击者很容易猜出后序的确认号,为了安全起见,避免被第三方猜到从而发送伪造的RST报文,因此ISN是动态生成的

    什么是半连接队列

    :服务器第一次收到客户端的SYN之后,就会处于SYN_RECD状态,此时双方还没有完全建立连接。服务器会把这种状态下的请求连接放在一个队列里,我们把这种队列称之为半连接队列。当然还有一个全连接队列,就是已经完成三次握手,建立起来连接的就会放在全连接队列中,如果队列满了就有可能出现丢包现象

    优雅回答四次挥手

    四次挥手客户端主动调用close时,向服务端发送结束报文段FIN报,同时进入FIN_WAIT1状态;服务器会收到结束报文段FIN报,服务器返回确认报文段ACK并进入CLOSE_WAIT状态,此时如果服务端有数据要发送的话,客户端依然需要接收。客户端收到服务器对结束报文段的确认,就会进入到FIN_WAIT2状态,开始等待服务器的结束报文段;服务器端数据发送完毕后,当服务器真正调用close关闭连接时,会向客户端发送结束报文段FIN包,此时服务器进入LAST_ACK状态,等待最后一个ACK的带来;客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出送确认报文段ACK;服务器收到了对结束报文段确认的ACK,进入CLOSED状态,断开连接。而客户端要等待2MSL的时间,才会进入到CLOSED状态

    在这里插入图片描述

    为什么握手是三次,而挥手时需要四次呢?

    :其实在TCP握手的时候,接收端将SYN包和ACK确认包合并到一个包中发送的,所以减少了一次包的发送。对于四次挥手,由于TCP是全双工通信,主动关闭方发送FIN请求不代表完全断开连接,只能表示主动关闭方不再发送数据了。而接收方可能还要发送数据,就不能立即关闭服务器端到客户端的数据通道,所以就不能将服务端的FIN包和对客户端的ACK包合并发送,只能先确认ACK,等服务器无需发送数据时在发送FIN包,所以四次挥手时需要四次数据包的交互

    TIME_WAIT状态有什么作用,为什么主动关闭方没有直接进入CLOSED状态释放资源?

    :如果主动关闭方进入CLOSED状态后,被动关闭方发送FIN包后没有得到ACK确认,超时后就会重传一个FIN包。如果客户端没有TIME_WAIT状态而直接进入CLOSED状态释放资源,下次启动新的客户端就可能使用了与之前客户端相同的地址信息,有两个危害,第一种是这个刚启动的新的客户端绑定地址成功时,就会收到了一个重传的FIN包,对新连接就会造成影响。第二种是如果该新客户端向相同的服务端发送SYN连接请求,但是此时服务端处于LAST_ACK状态,要求收到的是ACK而不是SYN,因此就会发送RST重新建立请求。

    为什么TIME_WAIT状态需要经过2MSL才能进入CLOASE状态?

    MSL指的是报文在网络中最大生存时间。在客户端发送对服务端的FIN确认包ACK后,这个ACK包有可能到达不了,服务器端如果接收不到ACK包就会重新发送FIN包。所以客户端发送ACK后需要留出2MSL时间(ACK到达服务器器+服务器发送FIN重传包,一来一回)等待确认服务器端缺失收到了ACK包。也就是说客户端如果等待2MSL时间也没收到服务器端重传的FIN包,则就可以确认服务器已经收到客户端发送的ACK包

    一台主机上出现大量的TIME_WAIT是什么原因?应该如何处理?

    :TIME_WAIT是主动关闭方出现的,一台主机出现大量的TIME_WAIT证明这台主机上发起大量的主动关闭连接。常见于一些爬虫服务器。这时候我们应该调整TIME_WAIT的等待时间,或者开启套接字地址重用选项

    一台主机上出现大量的CLOSE_WAIT是什么原因?应该如何处理?

    :CLOSE_WAIT是被动关闭方收到FIN请求进行回复之后的状态,等待上层程序进一步处理,若出现大量CLOSE_WAIT,有可能是被动关闭方主机程序中忘了最后一步断开连接后调用close释放资源。这是一个 BUG.,只需要加上对应的 close 即可解决问题

    tcp连接管理中的保活机制

    :tcp通信中,若两端长时间没有数据往来,则这时候每隔一段时间,服务端会向客户端发送一个保活探测数据报,要求客户端进行回复。若连续多次没有收到响应,就认为连接已经断开。长时间默认为7200s,每隔一段时间默认为75s,连续多次无响应默认为9次。这些数据都可以在套接字中修改,接口:Setsockopt

    展开全文
  • 倘若利用TCP协议,则传输前有三次握手,传输后有三次挥手,是一个可靠传输。 倘若利用UDP协议,传输前不需要建立连接,对方收到后也不需要发送确认,是一个不可靠的传输,但是胜在消耗资源少,速度快。 2.三次握手 ...
  • TCP三次握手与四次挥手.pdf
  • TCP三次握手.docx

    2021-05-26 22:15:01
    TCP三次握手.docx
  • TCP三次握手及四次挥手
  • wireshark tcp三次握手

    2016-08-03 09:05:18
    ubuntu下自己写tcp协议(server.c,client.c,Makefile),通过tcpdump生成 .cap文件后,利用wireshark分析tcp三次握手的整个过程
  • TCP三次握手 四次挥手

    千次阅读 多人点赞 2017-08-19 16:52:25
    TCP三次握手 四次挥手预备知识TCP的标志位 SYN(请求建立连接) ACK(确认) PSH(传送) FIN(结束) RST(重置) URG(紧急) TCP是面向连接的字节流协议,是全双工的。三次握手例图: 第一次握手:客户端发送一个连接请求...
  • 主要为大家介绍了网络协议之tcp协议,TCP三次握手与四次断开是怎么的一种情况呢,下面我们来看看观察TCP三次握手与四次断开,需要的朋友可以参考下
  • TCP 三次握手

    千次阅读 2012-09-01 21:41:04
    TCP(Transmission Control Protocol) 传输控制...TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接: 位码即tcp标志位, 有6种标示: SYN(synchronous建立联机) AC
  • TCP三次握手,四次挥手这是一个非常重要的知识点,我也来总结一下。 关于面试最经常问的问题无非就是: 握手为什么是3次? 2次可以吗? 为什么不是4次呢? 你能不能详细的介绍一下TCP三次握手的详细过程? 能不能说...
  • 模拟TCP三次握手

    2012-07-26 23:40:06
    Socket模拟TCP三次握手,网上找到
  • TCP三次握手安全隐患

    2013-01-06 09:06:27
    TCP三次握手安全隐患, TCP三次握手机制并不是绝对安全的,存在着一些安全隐患和漏洞。
  • TCP 三次握手和四次挥手,面试题详解,图文并茂,欢迎技术交流
  • TCP三次握手和四次挥手详解(面试常见问题)

    万次阅读 多人点赞 2019-05-16 23:06:51
    大概两个月前,一位朋友在面试360集团时,在面试过程中被问及TCP三次握手和四次挥手的相关知识,他当时只知道大概,但当时面试官问他TCP三次握手过程中发送的数字是多少,他一下子就懵住了,因为这也是他第一次参加...
  • 本文主要介绍Wireshark基本介绍和学习TCP三次握手,这里详细整理了相关资料,并给出详细流程,有需要的小伙伴可以参考下
  • 详解TCP三次握手和四次挥手
  • 传输控制协议,TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接,文档介绍TCP三次握手和4次挥手过程以及详细实例介绍,
  • TCP三次握手: 废话不多说, 直接上代码以及图例 (为了让大家方便阅读, 都有自己验证过程的一些图片作为分享) 。 1. 了解 TCP Connection 1. 在了解 TCP 之前我们需要了解的一个概念 TCP Connection : 1. 在我们的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 153,903
精华内容 61,561
关键字:

tcp三次握手