你真的懂接口测试基础之TCP、UDP和TCP/IP协议组吗？

Python接口自动化测试框架实战系列文章第1篇
Python接口自动化测试框架实战系列文章第2篇

TCP与UDP的区别

TCP 是面向连接的，UDP 是面向无连接的
UDP程序结构较简单
TCP 是面向字节流的，UDP 是基于数据报的
TCP 保证数据正确性，UDP 可能丢包
TCP 保证数据顺序，UDP 不保证

TCP 为什么是可靠连接

通过 TCP 连接传输的数据无差错，不丢失，不重复，且按顺序到达。
TCP 报文头里面的序号能使 TCP 的数据按序到达
报文头里面的确认序号能保证不丢包，累计确认及超时重传机制
TCP 拥有流量控制及拥塞控制的机制

UDP 的主要应用场景

需要资源少，网络情况稳定的内网，或者对于丢包不敏感的应用，比如 DHCP 就是基于 UDP 协议的。
不需要一对一沟通，建立连接，而是可以广播的应用。因为它不面向连接，所以可以做到一对多，承担广播或者多播的协议。
需要处理速度快，可以容忍丢包，但是即使网络拥塞，也毫不退缩，一往无前的时候

基于 UDP 的几个例子

直播。直播对实时性的要求比较高，宁可丢包，也不要卡顿的，所以很多直播应用都基于 UDP 实现了自己的视频传输协议
实时游戏。游戏的特点也是实时性比较高，在这种情况下，采用自定义的可靠的 UDP 协议，自定义重传策略，能够把产生的延迟降到最低，减少网络问题对游戏造成的影响
物联网。一方面，物联网领域中断资源少，很可能只是个很小的嵌入式系统，而维护 TCP 协议的代价太大了；另一方面，物联网对实时性的要求也特别高。比如 Google 旗下的 Nest 建立 Thread Group，推出了物联网通信协议 Thread，就是基于 UDP 协议的

运行在TCP协议上的协议：

HTTP（Hypertext Transfer Protocol，超文本传输协议），主要用于普通浏览。
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL，安全超文本传输协议）,HTTP协议的安全版本。
FTP（File Transfer Protocol，文件传输协议），由名知义，用于文件传输。
POP3（Post Office Protocol, version 3，邮局协议），收邮件用。
SMTP（Simple Mail Transfer Protocol，简单邮件传输协议），用来发送电子邮件。
TELNET（Teletype over the Network，网络电传），通过一个终端（terminal）登陆到网络。
SSH（Secure Shell，用于替代安全性差的TELNET），用于加密安全登陆用。

运行在UDP协议上的协议：

BOOTP（Boot Protocol，启动协议），应用于无盘设备。
NTP（Network Time Protocol，网络时间协议），用于网络同步。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置IP地址。

TCP/IP 四层协议

1.四层协议

应用层
传输层
网络层
数据链路层
（物理层）

你真的懂接口测试基础之TCP、UDP和TCP/IP协议组吗？

2.TCP/IP分层的目的：
（1）将网络的通信过程划分为小一些、简单一些的部件，有助于各个部件的开发、设计和故障排除；
（2）通过网络组件的标准化，允许多个供应商开发，鼓励产业标准化；
（3）允许各种类型的网络硬件和软件相互通信；
（4）防止某一层的改动影响到其它层，有利于开发（主要）。

3.各层的主要协议：

（1）应用层： HTTP(超文本传输协议 80), HTTPS(更安全的超文本传输协议 443), FTP(文件传输协议), SMTP(简单邮件传输协议), DNS(域名服务)，ping命令（调试网络环境），OSPF(开放最短路径优先)；
应用层处理应用程序的逻辑，且应用层在用户空间。

（2）传输层： UDP(用户数据报协议), TCP(传输控制协议)；
传输层采用端到端的通信方式，其中：
UDP：不可靠的，无连接的，基于数据报的协议；
TCP：可靠的，面向连接的，基于字节流的协议；

（3）网络层： IP(因特网协议), ICMP(控制报文协议), ARP(地址解析协议), RARP(反向地址转换协议)；
网络层主要实现数据包的选路和转发。

（4）数据链路层：传输单位是帧，分为逻辑链路控制子层（LLC），媒体访问控制子层（MAC）；
数据链路层是网卡接口的驱动程序，处理数据在物理媒介的传输

（5）物理层：传输单位是比特流
传输的主要介质：集线器、中继器、调制解调器、网线、双绞线、同轴电缆。

一次完整的HTTP请求与响应涉及了哪些知识？
答：包括TCP三次握手和TCP的四次挥手

TCP 三次握手建立连接

所有的问题，首先都要建立连接，所以首先是连接维护的问题(而UDP是不需要确认的，直接传输数据)
TCP 的建立连接称为三次握手，可以简单理解为下面这种情况：

A：您好，我是 A
B：您好 A，我是 B
A：您好 B

至于为什么是三次握手我这里就不细讲了，可以看其他人的博客，总结的话就是通信双方全都有来有回
对于 A 来说它发出请求，并收到了 B 的响应，对于 B 来说它响应了 A 的请求，并且也接收到了响应。

TCP 的三次握手除了建立连接外，主要还是为了沟通 TCP 包的序号问题。

A 告诉 B，我发起的包的序号是从哪个号开始的，B 同样也告诉 A，B 发起的包的序号是从哪个号开始的。

双方建立连接之后需要共同维护一个状态机，在建立连接的过程中，双方的状态变化时序图如下所示：
状态变化时序图
你真的懂接口测试基础之TCP、UDP和TCP/IP协议组吗？

第一次握手：

客户端想要连接，创建传输控制块TCB，状态变为主动打开。发送给服务器不包含数据内容的连接请求报文。该请求报文首部中同步位SYN=1，同时选择一个初始***seq=x（携带了x个字节）。然后客户端进入 SYN-SENT （同步已发送）状态，告诉服务器我想和你同步连接。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。

第二次握手：

TCP服务器收到连接请求报文，如果同意连接则发送确认报文。为了保证下次客户端发送报文时seq***是正确的，需要发送确认号ack=x+1，同时确认号ack要生效必须发送ACK=1，再加上同步位SYN=1，***seq=y（携带Y个字节），然后服务器也进入SYN-RCVD (同步已收到) 状态，完成同步连接。这个报文也是SYN报文，也不能携带数据，但是同样要消耗一个序号。

第三次握手：

客户端收到确认后还要再向服务器发送确认报文。确认报文已经不是请求报文SYN了，不再包含SYN同步位。发送的内容有***seq=x+1（和第二次握手的ACK对应），确认号ack=y+1，ACK=1。客户端发送确认报文以后进入ESTABLISHED（已建立）状态，服务器接收到确认报文以后也进入ESTABLISHED状态。此时TCP连接完成建立。

然后就可以发送TCP接收到Http的数据包后生成的新数据包了！

TCP 四次挥(分)手断开连接

说完建立连接，再说下断开连接，也被称为四次挥手，可以简单理解如下

A：B 啊，我不想玩了
B：哦，你不想玩了啊，我知道了
这个时候，只是 A 不想玩了，即不再发送数据，但是 B 可能还有未发送完的数据，所以需要等待 B 也主动关闭。
B：A 啊，好吧，我也不玩了，拜拜
A：好的，拜拜

这样整个连接就关闭了，当然上面只是正常的状态，也有些非正常的状态（比如 A 说完不玩了，直接跑路，B 发起的结束得不到 A 的回答，不知道该怎么办或则 B 直接跑路 A 不知道该怎么办），TCP 协议专门设计了几个状态来处理这些非正常状态

你真的懂接口测试基础之TCP、UDP和TCP/IP协议组吗？

解读：断开的时候，当 A 说不玩了，就进入 FIN_WAIT_1 的状态，B 收到 A 不玩了的消息后，进入 CLOSE_WAIT 的状态。

A 收到 B 说知道了，就进入 FIN_WAIT_2 的状态，如果 B 直接跑路，则 A 永远处于这个状态。TCP 协议里面并没有对这个状态的处理，但 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间。

如果 B 没有跑路，A 接收到 B 的不玩了请求之后，从 FIN_WAIT_2 状态结束，按说 A 可以跑路了，但是如果 B 没有接收到 A 跑路的 ACK 呢，就再也接收不到了，所以这时候 A 需要等待一段时间，因为如果 B 没接收到 A 的 ACK 的话会重新发送给 A，所以 A 的等待时间需要足够长。

第一次挥手：

客户端从ESTABLISHED状态变为主动关闭状态，客户端发送请求释放连接报文给服务器，FIN=1，seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

第二次挥手：

服务器接收到客户端发来的请求释放报文以后，发送确认报文告诉客户端我收到了你的请求，内容差不多就是seq=v，ack=u+1，ACK=1，此时服务器进入CLOSE-WAIT（关闭等待）状态。

为什么是CLOSE-WAIT状态？可能自己服务器这端还有数据没有发送完，所以这个时候整个TCP的连接就变成了半关闭状态。服务器还能发送数据，客户端也能接收数据，但客户端不能再发送数据了，只能发送确认报文。

客户端接收到服务器传来的确认报文以后，进入 FIN-WAIT-1（终止等待2）状态，等待服务器发送连接释放的报文（在这之前，还需要接受服务器没有发送完的最后的数据）。

第三次挥手：

服务器所有的数据都发送完了，认为可以关闭连接了，于是向客户端发送连接释放报文，内容FIN=1，seq=w，ack=u+1（客户端没发送消息，所以提醒客户端下一次还是从u+1开始发送序列），ACK=1。此时服务器进入了 LAST-ACK（最后确认）状态，等待客户端发送确认报文。

第四次挥手：

客户端接收到了服务器发送的连接释放报文，必须发出确认。确认报文seq=u+1，ack=w+1，ACK=1。此时客户端进入 TIME-WAIT （时间等待）状态，但是没有立马关闭。此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

Appium往期推文：