测试需知的TCP3次握手、4次挥手及10道经典面试题

一

网络的五层划分

我们先复习一下大学计算机老师讲过的网络五层划分：

• 应用层，常见协议： HTTP (Hyper Text Transfer Protocol), FTP(文件传输协议) DNS（域名解析协议）
• 传输层，常见协议： TCP(传输控制协议) UDP(用户数据报协议)
• 网络层，常见协议：IP
• 数据链路层
• 物理层

1.接下来，我们先了解一下TCP：

（1）TCP 是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如 IP 地址、端口号等。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等，对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。

（2）TCP 可以看成是一种字节流，它会处理 IP 层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在 TCP 头部，TCP 提供了一种可靠、面向连接、字节流、传输层的服务：

采用三次握手建立一个连接；

采用四次挥手来关闭一个连接。

2.再来说说UDP：

UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

二

常用的端口

三

TCP报文

我们具体来认识 TCP 的报文格式，下面是 TCP 报文格式图:

上图中有几个字段需要重点介绍下：

• 序号 Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
• 确认序号 Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
• 标志位 共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：

（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。

需要注意的是： 1.不要将确认序号Ack与标志位中的ACK搞混了。 2.确认方Ack=发起方Req+1，两端配对

四

3次握手

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

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之间可以开始传输数据了。

（4）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

五

4次挥手

其实三次握手大家都耳熟能详，四次挥手估计就少有人知道了。所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。

第一次挥手：

Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：

Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

第三次挥手：

Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：

Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况。

四次挥手补充：

a. 默认情况下(不改变socket选项)，当你调用close( or closesocket，以下说close不再重复)时，如果发送缓冲中还有数据，TCP会继续把数据发送完。

b. 发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。

c. 应用层如何知道对端关闭？通常，在最简单的阻塞模型中，当你调用recv时，如果返回0，则表示对端关闭。在这个时候通常的做法就是也调用close，那么TCP层就发送FIN，继续完成四次握手。如果你不调用close，那么对端就会处于FIN_WAIT_2状态，而本端则会处于CLOSE_WAIT状态。这个可以写代码试试。

d. 在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关闭，你可以写代码试试。

六

10道常见面试题

(1) 三次握手是什么或者流程？四次握手呢？

具体解析coco小锦鲤已经在前面介绍了，自己组织语言精简的表述出来就好了。

(2) 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

(3) 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

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

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

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

假设在12.106.32.254的1500端口和206.168.1.112.219的21端口之间有一个TCP连接。我们关闭这个链接，过一段时间后在 相同的IP地址和端口建立另一个连接。后一个链接成为前一个的化身。因为它们的IP地址和端口号都相同。TCP必须防止来自某一个连接的老的重复分组在连 接已经终止后再现，从而被误解成属于同一链接的某一个某一个新的化身。为做到这一点，TCP将不给处于TIME_WAIT状态的链接发起新的化身。既然 TIME_WAIT状态的持续时间是MSL的2倍，这就足以让某个方向上的分组最多存活msl秒即被丢弃，另一个方向上的应答最多存活msl秒也被丢弃。通过实施这个规则，我们就能保证每成功建立一个TCP连接时。来自该链接先前化身的重复分组都已经在网络中消逝了。

(4) 为什么不能用两次握手进行连接？

我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

(5) TCP协议和UDP协议的区别是什么？

• TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
• TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
• TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
• TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
• TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
• TCP面向的是字节流的服务，UDP面向的是报文的服务。

(6) 三次握手建立连接时，发送方再次发送确认的必要性？

主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多资源就这样白白浪费了。

(7) 四次挥手释放连接时，等待2MSL的意义？

1.为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。

2.就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

(8) 常见的应用中有哪些是应用TCP协议的，哪些又是应用UDP协议的，为什么它们被如此设计？

1.多播的信息一定要用udp实现，因为tcp只支持一对一通信。

2.如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，它直接对上层应用的数据封装成报文段，然后丢在网络中，如果信息量太大，会在链路层中被分片，影响传输效率。

3.如果一个应用场景重性能甚于重完整性和安全性，那么适合于udp，比如多媒体应用，缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较适合用udp

4.如果要求快速响应，那么udp听起来比较合适

5.如果又要利用udp的快速响应优点，又想可靠传输，那么只能考上层应用自己制定规则了。

6.常见的使用udp的例子：ICQ,QQ的聊天模块。

(9) HTTP 请求响应常见状态码有哪些？

1.100~199：表示成功接收请求，要求客户端继续提交下一欠请求才能完成整个处理过程；

2.200~299：表示成功接收请求并已完成整个处理过程(常用200)；

3.300~399：为完成请求，客户需进一步细化请求;

例如:请求的资源已经移动一个新地址、常用302 (意味着你请求我，我让你去找别人) ；

307和304 (我不给你这个资源，自己拿缓存);

4. 400~499：客户端的请求有错误;

例如：404 (意味着你请求的资源在web服务器中没有);

403 (服务器拒绝访问，权限不够);

5.500~599：服务器端出现错误，常用500;

(10) 你知道哪些常见的端口及用途？

1.代理服务器常用以下端口:

(1).HTTP协议代理服务器常用端口号: 80/8080/3128/8081/9080

(2).SOCKS代理协议服务器常用端口号: 1080

(3).FTP (文件传输)协议代理服务器常用端口号: 21

(4).Telnet (远程登录)协议代理服务器常用端口: 23

2.HTTP服务器，默认的端口号为80/tcp (木马Executor开放此端口);

HTTPS (安全传输网页)服务器，默认端口号为443/tcp 443/udp;

Telnet(不安全的文本传送),默认端口号为23 / tcp(木马微型Telnet服务器所开放的端口);

FTP,默认的端口号为21/tcp (木马Doly Trojan、Fore所开放的端口) ;

TFTP（测试用的文件传输协议），默认的端口号为69/udp;

SSH (安全登录)、SCP(文件传输)、端口重定向，默认的端口为22/tcp;

smtp(简单邮件传输协议)，默认的端口号为25/tcp(木马抗原，电子邮件密码发件人都开放这个端口);

3.POP3 Post Office Protocol (E-mail)，默认的端口号为110/tcp;

WebLogic,默认的端口号为7001;

Webshpere应用程序，默认的端口号为9080;

webshpere管理I具，默认的端口号为9090;

JBOSS,默认的端口号为8080;

TOMCAT,默认的端口号为8080;

WIN2003远程登陆，默认的端口号为3389;

Symantec AV/Filter for MSE,默认端口号为8081;

Oracle数据库，默认的端口号为1521;

ORACLE EMCTL,默认的端口号为1158;

Oracle XDB (XML数据库)，默认的端口号为8080;

Oracle XDB FTP服务，默认的端口号为2100;

MS SQL SERVER数据库server,默认的端口号为1433/tcp 1433/udp;

MS SQL SERVER数据库monitor,默认的端口号为1434/tcp 1434/udp;

QQ，默认的端口号为1080/udp