HCIA——二、TCP及其三次握手，问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了HCIA——二、TCP及其三次握手，问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

HCIA所有内容：

1、七层参考模型及IP讲解
2、TCP三次握手讲解
3、TCP四次挥手讲解及抓包分析
4、DHCP协议讲解及抓包分析
5、静态综合实验讲解
7、静态路由讲解
8、RIP路由信息协议讲解
9、动态路由协议讲解
10、抓包进行分析RIP以及OSPF的包
11、动态路由OSPF配置综合实验讲解
12、Vlan虚拟局域网技术讲解
13、ACL访问控制列表讲解
14、NAT技术讲解
15、网络综合实验讲解

TCP（传输控制协议）

名字得知肯定传输层协议。
面向连接： 因为在一个应用进程开始向另一个应用进程发送数据之前，这两个进程必须先相互“握手”，也就是说它们必须相互发送某些预备报文段，来确保数据传输的参数。
提供全双工服务： 如果一台主机上的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据就可在从进程B流向进程A的；同时，也从进程A流向进程B。
点对点连接： 单个发送方与单个接收方之间的连接。

TCP报文段结构：

TCP为每块客户数据配上一个TCP首部，从而形成多个TCP报文段。
TCP报文段由首部字段和一个数据字段组成，数据字段包含一块应用数据。
HCIA——二、TCP及其三次握手，问题,计算机网络,HCIA,tcp/ip,网络,服务器
由上图可知，TCP与UDP相同，首部都包含源端口号以及母的端口号。
（用于多路复用/分解来自或送到上层应用的数据）
同时都包含了检验和字段。
32比特的序号字段以及32比特的确认号字段：
用来实现可靠数据传输服务。
16比特的接受窗口字段： 用于流量控制。
4比特的首部长度字段： 指示了以32比特的字为单位的TCP首部长度。
由于TCP选项字段的原因，TCP首部的长度是可变的，通常情况下，选项字段为空，所以TCP首部的典型长度为20字节。
可选与变长的选项字段： 用于发送方与接收方协商最大报文长度（MSS）时，或在高速网络环境下用作窗口调节因子时使用。
6比特的标志字段 ACK比特用于指示确认字段中的值是有效的，即该报文段包括一个对已被成功接收报文段的确认。

序号和确认号

序号

TCP报文段首部中两个最重要的字段是序号字段和确认号字段，是TCP可靠传输服务的关键部分。
TCP把数据看成一个无结构的，有序的字节流
一个报文段的序号 是报文段首字节的字节流编号。
举个例子：数据流由一个包含40000字节的文件组成，其MSS为1000字节，数据流的首字节编号为0。
MSS： 最大报文段长度（不包含首部）
那么，该TCP就会为数据流构建500个报文段，给第一个报文段分配序号0，第二个报文段分配序号1000，第三个报文段分配序号2000，那么每个序号被填入相应的TCP报文段首部的序号中。

确认号

首先TCP是全双工的，那么两个主机之间肯定可以相互发送且接收数据（都是同一条TCP连接的一部分）。
主机A填充报文段的确认号是主机A期望从主机B收到的下一字节的序号。

三次握手全过程

HCIA——二、TCP及其三次握手，问题,计算机网络,HCIA,tcp/ip,网络,服务器
首先， TCP采用三次握手的目的：
1.要使每一方能够确知对方的存在。
2.要允许双方协商一些参数。
比如：最大报文段长度，最大窗口大小，服务质量等。
3.能够对传输实体资源进行分配。
比如：缓存大小，连接表中的项目等

假定左边主机为客户端s，右边为服务端c

第一次握手：

主机A向主机B发送TCP连接请求数据包，其中包含了主机A的初始序列号seq=x（随机生成的）。
其中报文中同步标志位SYN=1，ACK=0：
表示这是一个TCP连接请求数据报文；
序列号seq=x：
表明传输数据时的第一个数据字节的序号为x。

第二次握手：

主机B收到了主机A的请求后，会发回连接确认数据包。（其实这就好比加上一个陌生人的微信，然后大多数人第一句都是你好，进行回复，也算是一种“机制协议”）
其中，确认报文段中，标识位SYN=1，ACK=1：
表示这是一个TCP连接响应的数据报文，其中包含了主机B的初始序列号，seq=y，以及主机B对主机A初始序号的确认号ack=seq+1=x+1

第三次握手：

主机A收到主机B的确认报文后，还需要做出确认，也就是发送一个序列号，seq=x+1，确认号为ack=y+1的报文。此时，主机B收到主机A的回复后，就可以数据传输了。

补充：

ACK： （Acknowledgment fieldsignificant）置1时表示确认号（AcknowledgmentNumber）为合法，为0的时候表示数据段不包含确认信息，确认号被忽略。
SYN： （Synchronize sequence numbers）用来建立连接，在连接请求中，SYN=1，ACK=0，连接响应时，SYN=1，ACK=1。即，SYN和ACK来区分Connection Request和Connection Accepted。

面试中可能问到的问题

1.三次握手中，第一次握手丢失了

当客户端C和服务器S建立连接的时候，第一步客户端会发出一个SYN报文包含客户端的初始的序列号，如果说SYN报文中间传输丢失的话，那么这个时候客户端收不到服务端应该传输的SYN-ACK报文，就会触发重传机制，重传SYN报文，并且重传的SYN报文的客户端序列号是不变的。

2.三次握手中，第二次握手丢失了

首先明白第二次握手的意义，就是服务器给客户端回复SYN-ACK的过程，而且第二次握手的报文中包含了客户端的第一次ACK的确认报文。
如果客户端并没有收到服务端发送的SYN-ACK的话，那么客户端就会认为自己发送的SYN丢失，于是继续重传SYN。不过，第二次握手的报文中还包含服务端回复给客户端的SYN。
当服务端发送完SYN-ACK后，它就会开始还等待接收客户端发送的ACK，不过，第二次握手的包已经丢失了，收不到ACK，所以这个时候服务端认为自己所发送的报文丢失了，就会重传SYN-ACK。

客户端：当客户端达到一定重传次数时，依旧没有收到来自服务端的连接确认数据包，此时就会断开连接。
服务端：服务端和客户端一样，不过，它等待的是客户端的第三次握手的确认报文。

3.三次握手中，第三次握手丢失了

当客户端收到服务端的SYN-ACK报文后，就会给服务端发送一个ACK报文，而第三次握手的ACK是对第二次握手的SYN的确认报文，所以当第三次握手丢失后，服务端接收不到客户端发送的ACK，就会认为发送的SYN-ACK丢失了，从而触发超时重传机制，重传SYN-ACK。

4.为什么两次握手不可以呢

为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。
例如：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。
如果不进行第三次握手： B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。如果采用了三次握手： 由于 A 实际上并没有发出建立连接请求，所以不会理睬 B 的确认，也不会向 B 发送数据。B 由于收不到确认，就知道 A 并没有要求建立连接。

5.为什么不需要四次握手？

首先，完全可靠的通信协议是不存在的。
在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。

6.服务端端收到客户端的 SYN 后，为什么还要传回 SYN？

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。
SYN 是 TCP / IP 建立连接时使用的握手信号。
在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK¹ 消息响应。
这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。