七、java-计算机网络-3

1.10 介绍一下tcp的三次握手。

参考回答

1. 第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

1.11 介绍一下tcp的四次挥手。

参考回答

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

1.12 为什么需要四次挥手？

参考回答

1. 四次挥手示意图

   

2. 四次挥手过程

   （1）客户端向服务器发送FIN控制报文段（首部中的 FIN 比特被置位）；

   （2）服务端收到FIN，回复ACK。服务器进入关闭等待状态，发送FIN;

   （3）客户端收到FIN，给服务器回复ACK，客户端进入等待状态（进入“等待”，以确保服务器收到ACK真正关闭连接）;

   （4）服务端收到ACK，链接关闭。

3. 四次挥手原因

   ​ TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当客户端发出FIN报文段时，只是表示客户端已经没有数据要发送了，客户端告诉服务器，它的数据已经全部发送完毕了；但是，这个时候客户端还是可以接受来自服务端的数据；当服务端返回ACK报文段时，表示它已经知道客户端没有数据发送了，但是服务端还是可以发送数据到客户端的；当服务端也发送了FIN报文段时，这个时候就表示服务端也没有数据要发送了，就会告诉客户端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

   ​ 简单地说，前 2 次挥手用于关闭一个方向的数据通道，后两次挥手用于关闭另外一个方向的数据通道。

1.13 为什么要有最后一次ACK？

参考回答

1. 三次握手示意图

   

2. 四次挥手过程

   （1）客户端发送一个SYN0给服务器（选择初始序列号，不携带任何数据）

   （2）服务器收到SYN0，回复SYN1和ACK（服务器分配缓存，选择自己初始序列号）

   （3）客户端收到SYN1、ACK，回复ACK（可以包含数据）

3. 为什么要有最后一次ACK

   ​ 客户端首先向服务器发送一个连接请求，但是可能这个连接请求走了远路，等了很长时间，服务器都没有收到，那么客户端可能会再次发送，此时服务器端收到并且回复SYN、ACK；在这个时候最先发送的那个连接请求到达服务器，那么服务器会回复一个SYN，ACK；但是客户端表示自己已经收到确认了，并不搭理这个回复，那么服务器可能陷入等待，如果这种情况多了，那么会导致服务器瘫痪，所以要发送第三个确认。

答案解析

1.14 说一说你对tcp抓包的理解。

参考回答

1. TCP抓包定义

   ​ tcp抓包是指通过抓取计算机访问Web网站过程抓到的数据包，分析验证TCP报文段的结构。可以用抓包工具进行抓包分析。

答案解析

​ 示例（wireshark抓包分析流程）：

​ Wireshark捕获的是网卡的网络包，当机器上有多块网卡的时候，需要先选择网卡。开始界面中的Interface List，即网卡列表，选择我们需要的监控的网卡。点击Capture Options，选择正确的网卡，然后点击"Start"按钮, 开始抓包。

​ 我们打开浏览器输入任意http网址，连接再关闭，比如：http://blog.csdn.net。然后，我们回到Wireshark界面，点击左上角的停止按键。查看此时Wireshark的抓包信息。在看抓包信息之前，先简单介绍下Wireshark界面的含义。其中，封包列表的面板中显示**编号、时间戳、源地址、目标地址、协议、长度，以及封包信息**。

​ 封包详细信息是用来查看协议中的每一个字段。各行信息分别对应TCP/IP协议的不同层级。以下图为例，分别表示：传输层、网络层、数据链路层、物理层，一共四层。如果有应用层数据会显示第五层，即一共会出现五层。

​ 每一层都有一个字段指向上一层，表明上一层是什么协议。这大概是因为发包的时候会在数据上依次加上应用层、传输层、网络层、链路层的头部，但是对方收到数据包后是从最底层（链路层）开始层层剥去头部解包的，所以在每层上有一个字段指向上层，表明上层的协议，对方就知道下一步该怎么解包了。以TCP/IP协议为例，下图中分别是：IPv4、TCP。由于建立TCP连接用不到应用层协议，所以传输层就没有相应的指明上层(应用层)的字段了。

​ 在了解Wireshark界面后，我们来分析TCP协议。这里有很多数据包，我们需要先过滤，添加对应的过滤条件。比如，添加了目标的ip地址和端口号：tcp and ip.addr==47.95.47.253 and tcp.port==53992，此时获取到的封包列表如下。

​ 在此之前，看下TCP/IP报文的格式。

​ 根据上述报文格式我们可以将wireshark捕获到的TCP包中的每个字段与之对应起来，更直观地感受一下TCP通信过程。先看三次握手，下图中的3条数据包就是一次TCP建立连接的过程。

​ 第一次握手，客户端发送一个TCP，标志位为SYN=1，序号seq为Sequence number=0， 53992 -> 80，代表客户端请求建立连接；

​ 第二次握手，服务器向客户端返回一个数据包，SYN=1，ACK=1，80 -> 53992，将确认序号(Acknowledgement Number)设置为客户的序号seq(Sequence number)加1，即0+1=1；

​ 第三次握手，客户端收到服务器发来的包后检查确认序号(Acknowledgement Number)是否正确，即第一次发送的序号seq加1（X+1= 0+1=1）。以及标志位ACK是否为1。若正确，客户端会再向服务器端发送一个数据包，SYN=0，ACK=1，确认序号(Acknowledgement Number)=Y+1=0+1=1，并且把服务器发来ACK的序号seq(Sequence number)加1发送给对方，发送序号seq为X+1= 0+1=1。客户端收到后确认序号值与ACK=1，53992 -> 80，至此，一次TCP连接就此建立，可以传送数据了。

​ 还可以通过直接看标志位查看三次握手的数据包，如下图所示，第一个数据包标志位【SYN】，这是第一次握手；第二个数据包标志位【SYN,ACK】，这是第二次握手；第三个数据包标志位【ACK】，这是第三次握手。

​ 在三次握手的三个数据包之后，第四个包才是HTTP的， 这说明HTTP的确是使用TCP建立连接的。

​ 再往下看其他数据包，会发现存在大量的TCP segment of a reassembled PDU，字面意思是要重组的协议数据单元（PDU：Protocol Data Unit）的TCP段，这是TCP层收到上层大块报文后分解成段后发出去。

每个数据包的Protocol Length都是1502 Byte，这是因为以太网帧的封包格式为：Frame = Ethernet Header + IP Header + TCP Header + TCP Segment Data。即：

（1）Ethernet Header = 14 Byte = Dst Physical Address（6 Byte）+ Src Physical Address（6 Byte）+ Type（2 Byte），以太网帧头以下称之为数据帧。

（2）IP Header = 20 Byte（without options field），数据在IP层称为Datagram，分片称为Fragment。

（3）TCP Header = 20 Byte（without options field），数据在TCP层称为Stream，分段称为Segment（UDP中称为Message）。

（4）TCP Segment Data = 1448 Byte（从下图可见）。

所以，每个数据包的Protocol Length = 14 Byte + 20 Byte + 20 Byte + 1448 Byte = 1502 Byte。

我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释。

​ 第一次挥手：客户端给服务器发送TCP包，用来关闭客户端到服务器的数据传送。将标志位FIN和ACK置为1，序号seq=X=2242，确认序号ack=Z=17602，53992 -> 80；

​ 第二次挥手：服务器收到FIN后，服务器关闭与客户端的连接，发回一个FIN和ACK(标志位FIN=1,ACK=1)，确认序号ack为收到的序号加1，即X=X+1=2243。序号seq为收到的确认序号=Z=17602，80 -> 53992；

​ 第三次挥手：客户端收到服务器发送的FIN之后，发回ACK确认(标志位ACK=1),确认序号为收到的序号加1，即Y+1=17603。序号为收到的确认序号X=2243，53992 -> 80。

至此，整个TCP通信过程已经介绍完毕。

1.15 介绍一下tcp粘包、拆包的机制。

参考回答

1. TCP粘包和拆包问题

   ​ TCP是一个“流”协议，所谓流，就是没有界限的一长串二进制数据。TCP作为传输层协议并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

2. 产生TCP粘包和拆包的原因

   ​ 我们知道TCP是以流动的方式传输数据的，传输的最小单位为一个报文段（Segment）。TCP Header中有个Options标识位。常见的标识位为MSS（Maximum Segment Size）指的是，连接层每次传输的数据有个最大限制MTU（Maximum Transmission Unit），一般是1500bit，超过这个量要分成多个报文段，MSS则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460bit。换算成字节，也就是180多字节。

    TCP为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了以后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制来接受数据。

   发生TCP粘包、拆包主要是以下原因：

    （1）应用程序写入数据大于套接字缓冲区大小，会发生拆包；
    （2）应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发送粘包；
    （3）进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度——TCP header长度>MSS  的时候会发生拆包；
    （4）接收方法不及时读取套接字缓冲区数据，这将发生粘包。

3. 如何处理粘包和拆包

   ​ 假设应用层协议是http

   ​ 我从浏览器中访问了一个网站，网站服务器给我发了200k的数据。建立连接的时候，通告的MSS是50k，所以为了防止ip层分片，tcp每次只会发送50k的数据，一共发了4个tcp数据包。如果我又访问了另一个网站，这个网站给我发了100k的数据，这次tcp会发出2个包，问题是，客户端收到6个包，怎么知道前4个包是一个页面，后两个是一个页面。既然是tcp将这些包分开了，那tcp会将这些包重组吗，它送给应用层的是什么？这是我自己想的一个场景，正式一点讲的话，这个现象叫拆包。

   ​ 我们再考虑一个问题。

   ​ tcp中有一个negal算法，用途是这样的：通信两端有很多小的数据包要发送，虽然传送的数据很少，但是流程一点没少，也需要tcp的各种确认，校验。这样小的数据包如果很多，会造成网络资源很大的浪费，negal算法做了这样一件事，当来了一个很小的数据包，我不急于发送这个包，而是等来了更多的包，将这些小包组合成大包之后一并发送，不就提高了网络传输的效率的嘛。这个想法收到了很好的效果，但是我们想一下，如果是分属于两个不同页面的包，被合并在了一起，那客户那边如何区分它们呢？这就是粘包问题。

   ​ 从粘包问题我们更可以看出为什么tcp被称为流协议，因为它就跟水流一样，是没有边界的，没有消息的边界保护机制，所以tcp只有流的概念，没有包的概念。

   ​ 我们还需要有两个概念：

   ​ （1）长连接： Client方与Server方先建立通讯连接，连接建立后不断开， 然后再进行报文发送和接收。
   ​ （2）短连接：Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此种方式常用于一点对多点 通讯，比如多个Client连接一个Server。

   ​ 实际，我想象的关于粘包的场景是不对的，http连接是短连接，请求之后，收到回答，立马断开连接，不会出现粘包。 拆包现象是有可能存在的。

   ​ 处理拆包这里提供两种方法：

   ​ （1）通过包头+包长+包体的协议形式，当服务器端获取到指定的包长时才说明获取完整。
   ​ （2） 指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。

   ​ 处理粘包我们从上面的分析看到，虽然像http这样的短连接协议不会出现粘包的现象，但是一旦建立了长连接，粘包还是有可能会发生的。处理粘包的方法如下：

   ​ （1）发送方对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

   ​ （2）接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，判断每条数据的长度的方法有两种：

   ​ a. 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

   ​ b. 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

答案解析

​ 扩展资料

​ UDP会不会产生粘包问题呢？

​ TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

​ 举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。