你真的懂接口测试基础之TCPUDP和TCP/IP协议组吗?

Posted 软测小生

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了你真的懂接口测试基础之TCPUDP和TCP/IP协议组吗?相关的知识,希望对你有一定的参考价值。


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.各层的主要协议:

你真的懂接口测试基础之TCP、UDP和TCP/IP协议组吗? (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 发起的 包的序号是从哪个号开始的。
双方建立连接之后需要共同维护一个状态机,在建立连接的过程中,双方的状态变化时序图如下所示:
状态变化时序图

第一次握手:
客户端想要连接,创建传输控制块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 协议专门设计了几个状态来处理这些非正常状态


解读:断开的时候,当 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往期推文:





送书活动:

言+分享赠书

北大出版社《Python自动化测试实战》

(活动码004)
点击下图留言送书


文章合集

| |   

 |  |  | 

视频教程

| | | 


微信群:
软件自动化测试交流群
已创建,公号回复入群即可获取入群二维码。

以上是关于你真的懂接口测试基础之TCPUDP和TCP/IP协议组吗?的主要内容,如果未能解决你的问题,请参考以下文章

TCPUDP和HTTP

socket之tcpudp

TCPUDP以及HTTP的简单讲解

TCPUDP以及HTTP的简单讲解

[接口测试 - 基础篇] 01 你应该了解的协议基础

网络基础篇--TCP/IP协议族