计算机网络100问

已完成:协议模型、应用层、传输层。
待完成: 网络层、数据链路层
计算机网络知识点复习总结,持续更新中。。。
时间有限,可能存在部分纰漏和理解不当,欢迎指正交流。

计算机网络模型

1、五层因特网协议栈和七层OSI(Open System Interconnections)参考模型分别是什么?

5层:应用层、传输层、网络层、数据链路层、物理层
7层:应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

2、为什么考虑分层的架构,有什么优势和缺陷?

分层优势

协议分层具有概念化和结构化的优点。分层提供了一种结构化方式来讨论系统组件。模块化使更新系统组件更为容易。

分层缺陷

分层的一个潜在缺点是一层可能冗余较低层的功能。例如,许多协议栈在基于每段链路和基于端到端两种情况下,都提供了差错恢复。第二种潜在的缺点是某层的功能可能需要仅在其他某层才出现的信息(如时间戳值),这违反了层次分离的目标。

3、每一层的功能和作用分别是什么?每一层的传输数据类型是什么?

  1. 应用层(数据):确定两个通信端点上的进程之间通信的性质以满足用户需要以及提供网络与用户应用
  2. 表示层(数据):主要解决拥护信息的语法表示问题,如加密解密
  3. 会话层(数据):提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制,如服务器验证用户登录便是由会话层完成的
  4. 传输层(段):提供应用进程之间的逻辑通信,实现网络不同主机上用户进程之间的数据通信,可靠与不可靠的传输,传输层的错误检测,流量控制等
  5. 网络层(包):提供主机之间的逻辑通信,提供逻辑地址(IP)、选路,数据从源端到目的端的传输
  6. 数据链路层(帧):将上层数据封装成帧,用 MAC 地址访问媒介,错误检测与修正
  7. 物理层(比特流):设备之间比特流的传输,物理接口,电气特性等

4、每一层使用哪些数据交换设备?

  1. 网关:应用层、传输层(网关在传输层上以实现网络互连,是最复杂的网络互连设备,仅用于两个高层协议不同的网络互连。网关的结构也和路由器类似,不同的是互连层。网关既可以用于广域网互连,也可以用于局域网互连)
  2. 路由器:网络层(路由选择、存储转发)
  3. 交换机:数据链路层、网络层(识别数据包中的 MAC 地址信息,根据 MAC 地址进行转发,并将这些 MAC 地址与对应的端口记录在自己内部的一个地址表中)
  4. 网桥:数据链路层(将两个 LAN 连起来,根据 MAC 地址来转发帧)
  5. 集线器(Hub):物理层(纯硬件设备,主要用来连接计算机等网络终端
  6. 中继器:物理层(在比特级别对网络信号进行再生和重定时,从而使得它们能够在网络上传输更长的距离)

应用层

1、主流的应用程序体系结构是哪些?他们的优缺点是什么?

C/S模式(客户机/服务器)、P2P模式(对等方)、混合模式。

2、同一主机下和不同主机下的进程间是如何通信的?

同一主机下的进程间通信由操作系统决定。
不同的主机下的进程间通信通过消息/报文交换完成。

3、什么是套接字socket?套接字是用来干什么的?

套接字是个API,是应用程序和网络的接口。进程可类比于一座房子,而它的套接字可以类比于它的门。当一个进程想向位于另外一台主机上的另一个进程发送报文时,它把报文推出该门。

4、进程如何寻址?

主机地址(ip)+目的主机中指定接收进程的标识符(端口号)

5、应用层协议定义了哪些东西?

1.交换的报文的类型:请求报文或相应报文
2.报文类型的语法,每个字段是如何描述的
3.字段的语义
4.确定一个进程何时以及如何发送报文,以及报文的相应规则

6、web应用程序的应用层协议是什么?什么是无状态协议?

HTTP:超文本传输协议。所谓的无状态协议是指服务器向客户发送被请求的文件,而不存储任何关于该客户的状态信息。HTTP协议就是无状态协议。web应用利用cookie技术作为补充,弥补了HTTP协议无状态带来的可能缺陷。

7、什么是URL?格式是什么样的?

URL:统一资源定位器。用于web页面中对象的寻址,引用对应的对象。
一个web页面由多个对象组成,包括一个html基本文件和引用对象。引用对象用URL地址标识。
URL格式:协议://主机名/路径名(http://www.baidu.com/documents)(这里涉及到DNS解析域名和主机名)

8、什么是持续连接和非持续连接?概念前提是什么?优缺点分别是什么?http协议采用哪种连接方式?

考虑每个请求/响应是经过一个独立的TCP连接发送,还是所有的请求/响应经过相同的TCP连接发送。
前者为非持续连接(串行/并行),后者是持续连接(带流水/不带流水)。
前提:C/S模式,TCP???
HTTP协议既可以使用持续连接也可以使用非持续连接。默认情况下使用带流水线的持续连接。
带流水线的持续连接:http客户机遇到一个对象引用就发送一个请求,而不用等到前一个请求响应后再发送。

9、http报文类型及相应的报文格式

http请求报文格式:URL只包含路径名,主机名在首部行中hosts
在这里插入图片描述
http响应报文格式
在这里插入图片描述

10、http请求报文常用方法有哪些?分别是什么作用?

HTTP1.0:GET、POST、HEAD
HTTP1.1:GET、POST、HEAD、PUT、DELETE
GET:请求对象
POST:上传表单,一般放在实体体
HEAD:发送请求但不返回请求对象,常用于调试跟踪
PUT:允许用户上传对象到服务器
DELETE:允许用户删除服务器的某些对象

11、GET请求和POST请求的区别?

1.第一点区别:HTTP报文层面,GET将请求信息放到URL,请求信息与URL之间使用问号隔开,请求信息格式是键值对的形式,POST将请求信息放在报文体中,获取请求信息必须解析报文。GET请求是放在URL中的,URL本身是没有长度限制的,但是浏览器是有长度限制的,会对URL进行长度限制。POST是将请求信息放到报文体中的,所以对URL是没有长度限制的。
2.第二点区别:数据库层面,GET符合幂等性(对数据库的一次操作或者多次操作的结果是一致的,则认为符合幂等性)和安全性(对数据库的操作没有改变数据库的数据,则认为符合安全性的,GET操作是做查询操作的,因此不会改变数据库里面的数据),POST不符合(POST请求既不幂等也不安全,POST会向数据库中提交数据,所以会改变数据库里面的数据,POST每次获取到的结果都有可能不一样的,因为POST请求是作用在上一级的URL上面的,每一次请求都会添加新资源)。
3.第三点区别:GET请求可以被缓存(可以保存到浏览器的浏览记录中),被存储(GET请求URL可以被保存为浏览器书签),但是POST不行。

12、http响应报文常见状态码和相关短语有哪些?分别什么含义?

HTTP状态码

1xx,指示信息,表示请求已接收,继续处理。
2xx,成功,表示请求已被成功接收、理解、接受。
3xx,重定向,要完成请求必须进行更进一步的操作。
4xx,客户端错误,请求有语法错误或者请求无法实现。
5xx,服务器端错误,服务器未能实现合法的请求。

HTTP相关短语

200 OK:请求成功,信息返回在响应报文中
301 Moved Permanently:请求的对象被永久转移,新的URL定义在响应报文的首部行Location中
400 Bad Request:通用差错代码,表示请求不能被服务器响应
401 Unauthorized:请求未经授权
403 Forbidden:服务器收到请求但是拒绝服务
404 Not Found:请求的文档不在服务器上
500 Internal Server Error:服务器发生不可预期的错误
503 Server Unaviable:服务器当前不能处理客户机请求
505 HTTP Version Not Supported:服务器不支持请求报文使用的http协议版本

13、简述http请求响应的流程步骤。

1.客户端连接到web服务器,一个http客户端通常是浏览器与web服务器的http端口,默认端口号是80,建立一个tcp套接字连接。
2.然后发送http请求,即通过tcp套接字,客户端向web服务器发送一个文本的请求报文。
1.然后服务器接受到客户端的请求并返回HTTP响应。web服务器解析该请求定位请求资源,服务器将资源副本写到tcp套接字由客户端读取。
3.然后释放TCP连接。若连接模式是CLOSE,则服务器主动关闭tcp连接,客户端被动关闭tcp连接,释放tcp连接。若连接模式是keep alive,咋该连接会保持一段时间,在该时间内可以继续接受请求。
4.然后客户端浏览器解析HTML内容。并进行解析,客户端浏览器首先解析状态行,查看表名请求是否成功的状态代码,然后解析每一个响应头,响应头告知以下若干字节的HTML文档和文档的字符集,客户端浏览器读取响应数据HTML,根据html语法对其进行格式化,并在浏览器窗口中进行解释。

14、什么是cookie?其四大组件是什么?

cookie内容

cookie技术允许站点对用户进行跟踪。因为HTTP是无状态的,意味着每次访问有登录页面的需求的时候,都要输入账号和密码。Cookie技术是客户端的解决方案,是由服务器发送给客户端的特殊信息,以文本的形式存放在客户端。客户端每次向服务器发送请求的时候都会带上这些特殊信息,比如当客户使用浏览器访问支持Cookie的网站的时候,需要输入账号和密码提到到服务器,服务器向客户端回应超文本的同时将个人信息返回,个人信息不是存放在响应体http body中,而是保存到HTTP响应头http header中的,当客户端接收服务器的响应以后,浏览器将这些信息存放到统一位置。客户端再次请求的时候,会把Cookie发送到服务器中,Cookie信息存放到http响应头中。服务器接收到客户端浏览器的请求以后,会分析存放在请求头中的Cookie信息,得到客户端特有的信息,从而动态生成与该客户端相对应的内容。

cookie技术四大组件

1.在HTTP响应报文中的一个cookie首部行:set-cookie字段
2.在HTTP请求报文中的一个cookie首部行:cookie字段
3.在用户端系统中保留有一个cookie文件,并由用户的浏览器进行管理
4.位于Web站点的一个后端数据库

15、简述cookie的设置和发送流程。

Cookie的设置以及发送过程,第一步,客户端发送Http Requert请求到服务器。第二步,服务器端发送Http Response和设置Cookie头部到客户端。第三步,客户端Http Request和Cookie头部请求到服务器端。第四步,服务器端发送一个Http Response请求到客户端。

16、什么是Session?Session怎么利用cookie?

Session概念

由于HTTP协议是无状态的协议,所以服务端需要记录用户的状态时,就需要用某种机制来识具体的用户,这个机制就是Session.典型的场景比如购物车,当你点击下单按钮时,由于HTTP协议无状态,所以并不知道是哪个用户操作的,所以服务端要为特定的用户创建了特定的Session,用用于标识这个用户,并且跟踪用户,这样才知道购物车里面有几本书。这个Session是保存在服务端的,有一个唯一标识。在服务端保存Session的方法很多,内存、数据库、文件都有。集群的时候也要考虑Session的转移,在大型的网站,一般会有专门的Session服务器集群,用来保存用户会话,这个时候 Session 信息都是放在内存的,使用一些缓存服务比如Memcached之类的来放 Session。

session与cookie

思考一下服务端如何识别特定的客户?这个时候Cookie就登场了。每次HTTP请求的时候,客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的,第一次创建Session的时候,服务端会在HTTP协议中告诉客户端,需要在 Cookie 里面记录一个Session ID,以后每次请求把这个会话ID发送到服务器,我就知道你是谁了。有人问,如果客户端的浏览器禁用了 Cookie 怎么办?一般这种情况下,会使用一种叫做URL重写的技术来进行会话跟踪,即每次HTTP交互,URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数,服务端据此来识别用户。

17、cookie和session有什么区别?简述两者两者典型场景。

两者都是常用的会话跟踪技术。
1.cookie数据存放在客户的浏览器上,session数据放在服务器上。
2.cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗,考虑到安全应当使用session。
3.session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。

典型场景:登录网站,今输入用户名密码登录了,第二天再打开很多情况下就直接打开了。这个时候用到的一个机制就是cookie。session一个场景是购物车,添加了商品之后客户端处可以知道添加了哪些商品,而服务器端如何判别呢,所以也需要存储一些信息就用到了session。

18、什么是web缓存器?如何判断缓存的对象是否是最新的?

代理服务器,能够代表初始服务器满足http请求的网络实体。客户机请求先发送到代理服务器,代理服务器有请求内容直接响应,没有继续向上发送请求到初始服务器。能够做到快速响应,减少请求的响应时间,但是存在需要解决缓存数据新旧的问题。

条件GET方法:缓存服务器发送使用GET方法发送请求报文给初始服务器,并在报文首部行中包含“If-Modified-Since”字段。

19、什么是socket?

Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8kfPF2II-1612014040638)(.\socket.jpg)]

20、什么是HTTPS?它和HTTP有什么关系和区别?

HTTPS(Hyper Text Transfer Protocol Secure)是超文本传输安全协议。HTTPS是一种以计算机网络安全通信为目的的传输协议。HTTP是包含了ip、tcp、http,而HTTPS比HTTP新增了SSL(SSL3.0后改名为TLS)(具有保护交换数据隐私,以及完整性,提供对网上服务器身份认证的功能,是安全版的http)。
SSL(Securiy Sockets Layer,安全套接层),为网络通信提供安全以及数据完整性的一种安全协议,SSL位于TCP与各应用层之间,是操作系统对外的API,SSL3.0以后更名为TLS。采用身份验证和数据加密保证网络通信的安全和数据的完整性。

两者区别

1.HTTPS需要到CA申请证书,HTTP不需要。
2.HTTPS(Hyper Text Transfer Protocol Secure)是超文本加密传输协议,具有安全性的SSL加密传输协议,是密文传输,HTTP(Hyper Text Transfer Protocol)是超文本传输协议,是明文传输。
3.连接方式的不同,端口的不同,HTTPS默认使用的端口是443端口,HTTP默认使用的端口是80端口。
4.HTTPS=HTTP+加密+认证+完整性保护,SSL是有状态的,而HTTP连接是无状态的。

21、简述HTTPS的握手流程。

Https采用了证书和加密手段的方式保证数据的安全性。Https数据传输流程,Https在数据传输之前,会与网站服务器和web浏览器进行一次握手,在握手的时候确认双方的加密密码信息。
具体流程如下所示:

1.web浏览器将支持的加密算法信息发送给网站服务器。
2.服务器选择一套浏览器支持的加密算法,将验证身份的信息以证书的形式回发浏览器。
3.浏览器收到证书以后验证证书的合法性,如果证书受到浏览器信任,在浏览器地址栏有标志显示,否则显示不受信的标识。当证书受信以后,web浏览器随机生成一串密码,并使用证书中的公钥加密,之后使用约定好的hash算法握手消息b并生成随机数对消息进行加密,并将之前生成的信息回发给服务器。
4.服务器接收到web浏览器发送的消息以后,服务器使用私钥解密信息确认密码,然后通过密码解密web浏览器发送过来的握手信息,并验证哈希是否和web浏览器一致,加密新的握手响应消息回发浏览器。
5.web浏览器解密服务器经过哈希算法加密的握手响应消息,并对消息进行验真,如果和服务器发送过来的消息一致,则此握手过程结束以后,服务器和浏览器会使用之前浏览器生成的随机密码和对称密码进行加密,然后交换数据。

22、什么是DNS?它的名称空间是怎么样的(域名命名规范)?

DNS(Domain Name System)能进行主机名到IP地址转换的目录服务,此外还提供主机服务器别名、负载均衡(一个DNS名称可以对应多个IP地址)等功能服务。该系统由分层的DNS服务器实现的分布式数据库(根DNS服务器、顶级域DNS服务器(常见三类:组织域、国家域、反向域in-addr.arpa)、权威DNS服务器、本地DNS服务器(一般默认不属于层次结构的一层,但至关重要));一个使得主机能够查询分布式数据库的应用层协议。DNS协议运行在UDP之上,使用53号端口。

名称空间:完全限定域名(FQDN)主机名+域名
(大家一般默认主机名为www的设备为自己的服务器:www.baidu.com)
(子域名申请后,可以在子域名下自定义网络层次:www.bbs.xidian.edu.cn)

23、简述DNS解析原理和过程。

静态解析:把经常访问的IP存储在本地,通过访问本地文件获取响应的IP地址,称之为静态解析。比如:Linux操作系统会将部分主机名和IP映射存储在静态解析文件中/etc/hosts。
动态解析:DNS解析。
1.客户端拿着域名,请求DNS给查询出ip:正向解析(一般主机想本地DNS服务器迭代查询,本地DNS服务器向其他层级DNS服务器递归查询)
2.客户端拿着ip,请求DNS给查询出对应的全称域名:逆向解析(具体怎么做的?)

迭代查询和递归查询。(本地 ->root ->TLD ->权威)
如果考虑DNS缓存,本地服务器可以缓存TLD域名服务器的IP地址,在查询时直接访问TLD域名服务器,而不用通过根域名服务器再查询TLD域名服务器的IP。
一般情况下,DNS解析先访问浏览器缓存、其次查看本地hosts文件,再访问路由缓存查询,最后跑向DNS服务器。

24、简述DNS缓存。

DNS缓存即某DNS服务器在接收到某一主机名和IP地址的映射组时,会将该映射存储在本地,便于客户机的查询,提高响应速度。由于,主机名和IP地址的映射并不是永久性的,所以DNS服务器往往两天会丢弃缓存的映射信息。

25、简述FTP概念。

FTP(File Transfer Protocol,文件传输协议)。作为网络共享文件的传输协议,在网络应用软件中具有广泛的应用,FTP的目标是提高文件的共享性和可靠高效地传送数据。运行在TCP协议20(传输数据)、21(传输控制信息)端口上。但是,是否使用20作为传输数据的端口与FTP使用的传输模式有关,如果采用主动模式,那么数据传输端口就是20;如果采用被动模式,则具体最终使用哪个端口要服务器端和客户端协商决定。

26、FTP工作模式分别是哪两种?

主动方式:PORT方式

主动模式下,客户端随机打开一个N(N>1024)端口向服务器的命令端口 P,即 21 端口,发起连接,同时开放N +1 端口监听,并向服务器发出 “port N+1” (PORT h1,h2,h3,h4,p1,p2)命令,由服务器从它自己的数据端口 (20) 主动连接到客户端指定的数据端口 (N+1)。
FTP 的客户端只是告诉服务器自己的端口号,让服务器来连接客户端指定的端口。对于客户端的防火墙来说,这是从外部到内部的连接,可能会被阻塞。

被动方式:PASV方式

被动方式下,命令连接和数据连接都由客户端发起,这样就解决了从服务器到客户端的数据端口的连接被防火墙过滤的问题。被动模式下,当开启一个 FTP 连接时,客户端打开两个任意的本地端口 (N > 1024 和 N+1) 。
第一个端口连接服务器的 21 端口,提交 PASV 命令。然后,服务器会开启一个任意的端口 (P > 1024 ),返回如“227 entering passive mode (127,0,0,1,4,18)”。 它返回了 227 开头的信息,在括号中有以逗号隔开的六个数字,前四个指服务器的地址,最后两个,将倒数第二个乘 256 再加上最后一个数字,这就是 FTP 服务器开放的用来进行数据传输的端口。如得到 227 entering passive mode (h1,h2,h3,h4,p1,p2),那么端口号是 p1*256+p2,ip 地址为h1.h2.h3.h4。这意味着在服务器上有一个端口被开放。客户端收到命令取得端口号之后, 会通过 N+1 号端口连接服务器的端口 P,然后在两个端口之间进行数据传输。

两种模式的差异

由于防火墙机制,主动模式不利于客户端管理,被动模式不利于服务端管理。
主动情况下服务端数据端主动链接客户端可能遭到客户端防火墙拦截。
被动情况下客户端主动访问服务端数据端口可能遭到服务端防火墙拦截。

27、FTP各种指令和响应码。

28、简述FTP断点续传。

其实FTP断点续传的原理很简单,可分为断点下载和断点上传。
客户端的实现步骤如下:
一、下载:

1、向服务器发送“REST + 本地文件长度”命令,告诉服务器,客户端要断点下载了。这时服务器还不知道客户端要下载哪个文件; 要实现FTP的断点续传,FTP服务器必须支持REST指令,这条指令在FTP协议文本RFC959中就已经定义了,不过它不是FTP服务器必须支持的指令。一般,你可以在下载前使用REST 100命令进行实验,如果服务器正常执行了这条命令,说明该服务器支持FTP断点续传。REST后面跟的数表示下载文件的起始位置,而REST 0表示从文件最开始处下载。REST命令本身并不执行下载功能,你仍需要使用RETR命令执行下载工作。
2、向服务器发送“RETR + 文件名”命令,通知服务器要下载的文件名,这时服务器开始定位文件指针读文件并发送数据。
3、客户端定位本地文件指针(文件末尾);
4、两端的准备工作都做完了以后,客户端创建socket,以被动或非被动方式建立数据通道,循环调用recv接收数据并追加入本地文件;

二、上传:

1、获取服务器上和本地要上传文件的同名文件大小;
2、向服务器发送“APPE + 文件名”,通知服务器,接下来从数据通道发送给你的数据要附加到这个文件末尾。
3、定位本地文件指针(和FTP上文件大小相同的位置)
4、从文件指针处读数据并发送。

29、简述匿名FTP。

匿名FTP,即匿名文件传输协议。用于对远程计算机的连接,这些计bai算机是作为匿名或客户用户进行连接的,以将公共文件传输到用户的本地计算机。使用FTP时必须首先登录,在远程主机上获得相应的权限以后,方可上传或下载文件。也就是说,要想同哪一台计算机传送文件,就必须具有哪一台计算机的适当授权。匿名FTP就是为解决这个问题而产生的。互联网中有很大一部分FTP服务器称为“匿名”FTP服务器。这类服务器的目的是向公众提供文件拷贝服务,不要求用户事先在该服务器进行登记注册,也不用取得FTP服务器的授权。匿名文件传输能够使用户与远程主机建立连接并以匿名的身份从远程主机上拷贝文件,而不必是该远程主机的注册用户。提供服务的机构在它的FTP服务器上建立一个公开账户(一般为anonymous),并赋予该账户访问公共目录的权限。

30、简述DHCP。

动态主机配置协议。

31、端口号的基本参数。

端口号是16bit的数据,端口号范围为065535,其中01023是周知端口号。

32、简述TCP和UDP概念及区别。

TCP:传输控制协议,TCP是面向字符流面向连接的协议,应用程序产生的全体数据与真正发送的单个IP数据报可能没什么联系。
UDP:用户数据报协议,是一个简单的面向数据报的无连接运输层协议,进程的每个输出操作都正好产生一个UDP数据报,并组装成一份待发送的IP数据报。UDP协议只完成多路复用、多路分用和简单的错误检测的功能。

区别:

  1. TCP面向连接,UDP面向无连接
  2. TCP面向报文,UDP面向字节流
  3. TCP提供可靠传输服务(数据顺序、正确性),UDP传输不可靠
  4. TCP协议传输速度慢,UDP协议传输速度快
  5. TCP协议对系统资源要求多(头部开销大),UDP协议要求少
  6. TCP协议提供拥塞控制机制使得传输速率和时间不完全受应用程序控制,UDP没有拥塞控制使得应用程序可以更好地控制发送时间和速率

33、在UDP上如何实现可靠的数据传输?

在应用层增加可靠性机制和应用特定的差错恢复机制,增加了应用开发的难度。

34、简述UDP报文字段格式。

首部字段+数据字段。
UDP长度:包含字段首部和字段数据两部分的总长度。
检验和:检测UDP段在传输过程中是否发生错误。计算检验和时,除了UDP报文段(首部+数据字段)以外还包括了伪首部。

发送方:UDP对报文段中的所有16比特字的和进行反码运算, 求和时遇到的任何溢出都被回卷(回卷就是进位加到末位去)。
接收方:同理计算校验和,验证计算结果和校验和是否相等,不相等则说明检测出错误,但是相等并不代表没有错误。
在这里插入图片描述

35、什么是伪首部?伪首部有什么内容?为什么计算检验和时要增加伪首部?

伪首部只是虚拟的数据结构,在IP的分组头中提取出来用于计算检验和,而不通过实际的传输。
所有伪首部包括:源IP地址,目的IP地址,0,协议号,UDP长度。
伪首部的增加其目的是让UDP两次检查数据是否已经正确到达目的地(不仅需要报文内容正确还需要主机IP正确),可以确定目的IP地址是本机的(一次),操作系统将报文正确交付给了UDP(两次)。
在这里插入图片描述

36、什么是可靠传输协议(rdt)?有几种常见的可靠传输协议及其潜在的缺陷?

rdt1.0:可靠信道上的可靠数据传输
rdt2.0:仅具有比特差错信道的数据传输(差错检测、ACK/NAK机制、重传机制)
rdt2.1:在rdt2.0基础上,考虑ACK/NAK出错情况(引入序列号,接收方根据序列号判断是新分组还是重传的分组)
rdt2.2:在rdt2.0基础上,考虑没有NAK,ACK出错情况(接收方告知发送方最后一个被接收的分组序号)
rdt3.0:具有比特差错和分组分组丢失的信道数据传输(在上述基础上设置合理的等待时间)

37、为什么rdt停等协议性能并不高,有什么解决方案?

因为停等操作使得每一个分组发送出去都需要等待确认的时间,一轮RTT,导致效率并不高。可以采用流水线机制的rdt协议进行传输,不以停等方式运行,允许发送方发送多个分组而无须等待确认,以此增加效率。

38、采用流水线机制的可靠数据传输协议需要注意什么问题?

1.需要增加序列号的范围
2.需要发送方有更大的分组缓存空间
3.需要合适的差错恢复机制:滑动窗口协议(GBD(回退N步)、SR(选择重传))

39、简述回退N步(GBN)协议。

GBN协议中,发送方在发完一个数据帧后,连续发送若干个数据帧,即使在连续发送过程中收到了接收方发来的应答帧,也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器(同一个定时器)。只要在所设置的超时时间内仍未收到确认帧,就要重发相应的数据帧。如:当发送方发送了N个帧后,若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息,则该帧被判为出错或丢失,此时发送方就不得不重新发送出错帧及其后的N帧。
发送方仅使用一个定时器,它可被当作是最早的已发送但未被确认的分组所使用的定时器。如果收到一个ACK,但仍有已发送但未被确认的分组,则定时器被重新启动。如果没有已发送但未被确认的分组,停止该定时器。
接受帧只允许按顺序接受帧ACK(n)。为了减少开销,累计确认允许接收端在连续收到好几个正确的确认帧后,只对最后一个数据帧发确认信息,或者可以在自己有数据要发送时才将对以前正确收到的帧加以捎带确认。这就是说,对某一数据帧的确认就表明该数据帧和这以前所有的数据帧均已正确无误地收到了。(累计确认)
后退N帧协议的接受窗口为1,可以保证按序接受数据帧。若采用n个比特对帧编号,则其发送窗口的尺寸应满足:1~2(n-1)。若发送窗口的尺寸大于2(n-1),则会造成接受方无法分辨新帧和旧帧。
缺点: 丢失的帧出错,不仅要把丢失的帧重传,还要把丢失的帧之后的帧也得重传,传输效率降低了。

40、简述选择重传(SR)协议。

SR协议是当接收方发现某帧出错后,其后继续送来的正确的帧虽然不能立即递交给接收方的高层,但接收方可收下来,存放在一个缓冲区中,同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后,就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。显然,SR减少了浪费,但要求接收方有足够大的缓冲区空间。

发送窗口大小+接收窗口大小<=2^(n)。

41、从滑动窗口角度比较停等、GBN、SR三种协议。

若从滑动窗口的观点来统一看待停等、后退n及选择重传三种协议,它们的差别仅在于各自窗口尺寸的大小不同而已。停等:发送窗口= 1,接收窗口=1; 后退n协议:发送窗口>1,接收窗口=1;选择重传协议:发送窗口>1,接受窗口>1;

42、简述TCP报文字段格式。

序号:该报文段首字节的字节流编号,而不是段编号。
确认号:主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。也是采用累计确认的。(这点类似GBN)
标志字段:8位,分别代表不同含义。
接收窗口:该字段用于流量控制,用于指示接收方愿意接受的字节数量。
紧急数据指针:指向紧急数据在报文段中结束的位置。
选项字段:该字段用于发送方与接收方协商最大报文段长度(MSS)时使用。
在这里插入图片描述

43、TCP中接收方如何处理乱序到达的报文段?

规范中并没有规定,交给应用开发者决定。

44、TCP通过哪些方式保障数据传输的可靠性?

1.将应用数据被分割成 TCP 认为最适合发送的数据块。
2.确认机制,发送报文后,等待确认。
3.重发机制,没有收到确认,将重发数据段。
4.保持它首部和数据的校验和。 确认数据的准确性。
5.排序,丢弃重复的,流量控制。

45、简单介绍TCP三次握手原理。

1.第一次握手:建立连接时,客户端发送SYN同步包(syn=x)(不能携带数据)到服务器,并进入SYN_SEND状态即同步已发送,等待服务器确认。
2.第二次握手:服务器收到SYN包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y)(不能携带数据),即SYN+ACK包,此时服务器进入SYN_RECV状态即同步已收到(即server收到SYN同步包以后,同意建立连接,向client回复一个ACK。由于tcp是全双工传输的,server端同时向client端发送一个同步请求SYN,申请server端向client端建立连接,此时服务器进入SYN_RECV状态)。
3.第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTAB LISHED状态即连接已建立,完成三次握手(即client收到server的ack后,client端的连接状态变成了ESTABLISHED,同时client端向server端发送ack响应,回复server端的syn请求,server端收到client端的ack响应以后,server端的连接状态变成了ESTABLISHED。此时,建立连接完成,双方随时可以进行数据传输)。TCP的三次握手是为了建立双向的连接。
在这里插入图片描述

46、为什么需要三次握手,而不是二次或者四次?

首先,需要明确的是,TCP握手建立连接,核心思想是在保证数据传输可靠和提高传输效率的两个前提下,握手的目的是得到双方的数据原点的序列号Sequence Number。
为了初始化Sequence Number的初始化值。通信的双方要互相通知对方自己的初始化的Sequence Number值。即seq=x和seq=y,seq值要作为以后的数据通信的序号,以保证应用层接收到的数据不会因为网络上的传输问题而乱序,即Tcp会用这个序号进行拼接数据。因此在服务器回发它的Sequence Number即第二次握手之后,还需要客户端发送确认报文给服务器,告诉服务器客户端已经收到服务器的的初始化Sequence Number值。

不采用四次握手原因:可以将服务器对客户端SYN同步包的响应回复ACK,和服务器发送给客户端的SYN同步包合并起来,提高传输效率。
不采用两次握手原因:两次握手可能造成服务器和客户端就服务器的初始序列值没有达成一致。
TCP不会为没有数据的ACK重传!

47、首次握手的隐患SYN超时。问题起因分析。

Server服务器端收到Client客户端发送的SYN,Server服务器端回复Client客户端SYN-ACK的时候,如果此时Client客户端掉线了,Server服务器端未收到Client客户端的ACK确认。那么该连接就处于一个中间状态,即未连接成功也未连接失败状态。此时Server服务器端不断重试直至超时,Linux默认重试5次,重试间隔从1秒开始,每次翻倍,等待63秒钟,tcp才会断开连接。此时服务器可能遭受SYN Flood攻击的风险。
针对SYN Flood攻击风险的防护措施。比如恶意程序给服务器发送SYN报文,发送以后就进行了下线,然后服务器默认等待63秒才会断开,攻击者就会将服务器的SYN连接的队列耗尽,让正常的连接请求不能处理。Linux系统给出了一个方案,当SYN队列满后,通过tcp_syncookies参数回发SYN Cookie。TCP根据源地址端口,目标目的端口,时间戳生成一个特殊的Sequence Number即SYN Cookie回发给客户端。如果是攻击者是不会有响应的,若为正常连接则Client客户端会回发服务器端SYN Cookie,直接建立连接。通过SYN Cookie创建的连接,即使现在SYN队列满后,本次连接请求不在队列中,也可以创建连接。
如果建立连接后,Client客户端出现故障怎么办呢,其实TCP设置保活机制,在一段时间内,该时间被称为保活时间keep alive time,在这段时间内,连接处于非活动状态,开启保活功能的一端将向对方发送保活探测报文。向对方发送保活探测报文,如果发送端未收到响应报文,如果在保活时间内即提前配置好的keep alive time则继续发送。直到尝试次数达到保活探测数仍未收到响应则中断连接。对方直接将被确认为不可达,连接即被中断。

48、简单介绍TCP四次挥手原理。

1.第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态即中止等待1的状态(即tcp的四次挥手是为了断开连接,通信双方都可以先发起断开连接请求。这里以client作为先发起断开连接的一端,通信中的client、server都是ESTABLISHED的状态,client先发起来了关闭连接的请求,client端向server端发送了FIN包,表示client端没有数据要发送了,client端进入了FIN_WAIT_1状态了。)。
2.第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态即关闭等待状态(即server端收到FIN包以后,向client发送ACK确认,然后server端进入了CLOSE_WAIT状态,此时server属于半关闭状态,因为此时client不会再向server端发送数据了,server端向client端可能还要发送数据的,当server端数据发送完毕以后)。
3.第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态即最后确认状态(即当server端数据发送完毕以后,server端向client端发送FIN包,表示server端也没有数据要发送了,此时server进入了LAST_ACK状态,等待client端的应答就可以关闭连接了。)。
4.第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态即时间等待状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态即关闭状态,完成四次挥手(即client端收到server端的FIN后,回复ACK,进入TIME_WAIT状态,切记TIME_WAIT状态下,需要等待2倍的MSL最大报文段生存时间,来保证连接的可靠关闭,之后client进入CLOSE关闭状态,server收到client的ack以后,直接进入close状态。)。
在这里插入图片描述

49、为什么会有TIME_WAIT状态呢?

TIME-WAIT时间等待状态到CLOSE关闭状态,有一个超时设置,这个超时设置是2乘以MSL。为什么要等待这一段时间呢,TIME-WAIT状态主要是要确保有足够的时间让对方收到ACK包,如果被动关闭的哪一方没有收到ACK确认,就会触发被动端重发FIN包(FINISH包)一来一去正好是2乘以MSL。也避免了新旧连接混淆,不让这个连接和后面的连接混到一起。

50、为什么建立连接需要三次握手,而断开连接需要四次挥手才能断开连接呢?

全双工的意思是允许数据在两个方向上同时传输,即在同一时间服务器可以发送给客户端,客户端也可以发送数据给服务器。因为TCP是全双工,发送方和接收方都需要FIN报文和ACK报文,也就是说发送方和接收方各自需要两次挥手即可,只不过有一方是被动的,所以,看上去就变成了四次挥手。
无论是建立连接还是断开连接,都是从两个方向上进行,只不过建立连接的时候,server端的SYN和ACK包是合并为一次发送。而断开连接的时候,两个方向的数据发送的停止时间可能是不同的,所以无法合并FIN和ACK包,FIN和ACK是分开发送的。这就是建立连接的时候必须要三次握手,断开连接的时候要四次挥手的原因。

51、简述TCP同时打开流程。

两端的状态变化都是由CLOSED->SYN_SENT->SYN_RCVD->ESTABLISHED。
在这里插入图片描述

52、简述TCP同时关闭流程。

两端的状态变化都是由ESTABLISHED->FIN_WAIT_1->CLOSING->TIME_WAIT->CLOSED。
在这里插入图片描述

53、简述TCP半打开和半关闭流程。

半打开:
  TCP的半开连接是指TCP连接的一端异常崩溃,或者在未通知对端的情况下关闭连接,这种情况下不可以正常收发数据,否则会产生RST(后面内容我们在介绍RST)。比如一个常见的情况是TCP连接的一端异常断电,就会导致TCP的半开连接。如果没有数据传输,对端就不会知道本端的异常而一直处于ESTABLISHED状态(TCP有存活检测机制,后面内容我们会进行介绍)。
  另外从linux实现的角度来说,因为linux内部有个半连接队列,TCP半开连接是指发送了TCP连接请求,等待对方应答的状态,此时连接并没有完全建立起来,双方还无法进行通信交互的状态,此时就称为半连接。由于一个完整的TCP连接需要经过三次握手才能完成,这里把三次握手之前的连接都称之为半打开连接。

半关闭:
  TCP的半关连接是指TCP连接只有一方发送了FIN,另一方没有发出FIN包,仍然可以在一个方向上正常发送数据。这种场景并不常见,一般来说Berkeley sockets API调用shutdown()接口时候就会进入半关闭状态(调用常规的close()一般是期待完整的双向关闭这个TCP连接),shutdown()接口相当指示程序,本端已经没有数据待发送,所以我发送一个FIN到对端,但是我仍然想要从对端接收数据,直到对端发送一个FIN指示关闭连接为止。如下图所示,在红色背景文本框标注的数据传输场景下就是TCP的半关连接。
在这里插入图片描述

54、RTT往返时间估计。

RTT定义:报文段的样本RTT (表示为SampleRTT)就是从某报文段被发出(即交给IP)到对该报文段的确认被收到之间的时间量。大多数TCP的实现仅在某个时刻做一次SampleRTT测量,而不是为每个发送的报文段测量一个SampleRTT。
此外,TCP还维护EstimatedRTT和DevRTT两个参数,重传间隔的设置就依据这三个参数来设置。
SampleRTT的均值EstimatedRTT
EstimatedRTT = (1 - a) • EstimatedRTT + a • SampleRTT
RTT偏差
DevRTT = (1 -c) • DevRTT +c • | SampleRTT - EstimatedRTT |

55、TCP定时器超时时间间隔设置。

超时重传定时器(RTO)时间间隔设置:初始值建议设置为1s
Timeoutinterval = EstinMrtedRTT +4 • DevRTT
实际中,TCP在Timeoutinterval的动态变化中还需要考虑流量和拥塞控制情况,并不一定完全按照上述估计。
超时间隔加倍:TCP每次重传时都会将下一次的超时间隔设从EstimatedRTT为
先前值的两倍
,而不是用DevRTT和EstinmatedRTT推算出,主要是用于规避网络拥塞的风险。

56、TCP是一个GBN协议还是一个SR协议?

都不是,更像是一个结合体。
TCP确认是累积式的,正确接收但失序的报文段是不会被接收方逐个确认的,这点类似于GBN**(但是GBN的ack=已确认的序号,而TCP的ack=期待接下来收到的序号(和GBN差1))。因此,发送方仅需维持已发送过但未被确认的字节的最小序号和下一个要发送的字节的序号。但是,TCP会将正确接收但失序的报文段缓存起来**,这点类似于SR。TCP的选择确认机制,它允许TCP接收方有选择地确认失序报文段,而不是累积地确认最后一个正确接收的有序报文段。当将该机制与选择重传机制结合起来使用时(即跳过重传那些已被接收方选择性地确认过的报文段),TCP看起来就很像SR协议。TCP每个报文段维护一个计时器用于超时重传,这点类似于SR。

举个栗子:
在这里插入图片描述
在这里插入图片描述

57、TCP连接使用的四个计时器分别是什么?有什么作用?

1.超时重传计时器(60s):当TCP发送报文段时,就创建该特定报文段的重传计时器。
2.持续计时器(60s):用于流量控制,在接收端发送接收窗口大小=0报文后,发送端在持续计时器超时后,发送探询消息试探接收窗口的大小,以此来避免接收端重新发送>0的窗口报文给发送方时出现报文丢失,造成双方僵持等待的死锁情况。
3.保活计时器(2h):保活计时器用来防止两个TCP之间的连续出现长时间的空闲。
4.时间等待计时器(2MSL):当客户端进入TIME-WAIT状态的时候,链接还没有释放掉,必须等待2倍的MSL(最长报文段寿命)后,客户端才能关闭连接。在时间等待期间,链接还处于一种过渡状态。

58、简述TCP流量控制机制。

所谓的流量控制就是让发送方的发送速率不要太快,让接收方来得及接收。由于双方在通信的时候,发送方的速率与接收方的速率是不一定相等,如果发送方的发送速率太快,会导致接收方处理不过来,这时候接收方只能把处理不过来的数据存在缓存区里(失序的数据包也会被存放在缓存区里)。如果缓存区满了发送方还在疯狂着发送数据,接收方只能把收到的数据包丢掉,大量的丢包会极大着浪费网络资源。
利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。
**那怎么进行流量控制呢?**接收方每次收到数据包,可以在发送确定报文的时候,同时告诉发送方自己的缓存区还剩余多少是空闲的,我们也把缓存区的剩余大小称之为接收窗口大小。发送方收到之后,便会调整自己的发送速率,也就是调整自己发送窗口的大小,当发送方收到接收窗口的大小为0时,发送方就会停止发送数据,防止出现大量丢包情况的发生。
那发送方何时再继续发送数据呢? 当发送方收到接受窗口 win = 0 时,这时发送方停止发送报文,并且同时开启一个定时器(持续计时器),每隔一段时间就发个测试报文去询问接收方,打听是否可以继续发送数据了,如果可以,接收方就告诉他此时接受窗口的大小;如果接受窗口大小还是为0,则发送方再次刷新启动定时器。
那窗口大小怎么设置呢?

59、什么是AIMD?

AIMD(加法递增,乘法递减法则) 是TCP采用的拥塞控制法则。但是并不绝对公平,因为根据往返时间调整窗口的大小,这就造成接近主机的连接比远离主机的连接获得的带宽多。
在这里插入图片描述

60、简述TCP拥塞控制机制。

所谓拥塞控制就是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载
TCP拥塞控制机制有两个版本:TCP TahoeTCP Reno,两者的差别在于是否采用快速恢复机制

慢启动:

当新建连接时,cwnd初始化为1个最大报文段(MSS)大小,发送端开始按照拥塞窗口大小发送数据,每当有一个报文段被确认,cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(RTT)呈指数级增长,事实上,慢启动的速度一点也不慢,只是它的起点比较低一点而已。

拥塞避免:

从慢启动可以看到,cwnd可以很快的增长上来,从而最大程度利用网络带宽资源,但是cwnd不能一直这样无限增长下去,一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量,当cwnd超过该值后,慢启动过程结束,进入拥塞避免阶段。对于大多数TCP实现来说,ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大,也就是cwnd的值不再指数级往上升,开始加法增加。此时当窗口中所有的报文段都被确认时,cwnd的大小加1,cwnd的值就随着RTT开始线性增加,这样就可以避免增长过快导致网络拥塞,慢慢的增加调整到网络的最佳值。

快速重传:

TCP对每一个报文段都有一个定时器,称为重传定时器(RTO),当RTO超时且还没有得到数据确认,那么TCP就会对该报文段进行重传,此时,发送端就认为网络处于拥塞状态。
采用快速重传的前提要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认,快速重传可以提升网络吞吐量。TCP在收到乱序到达包时就会立即发送ACK,TCP利用3个相同的ACK来判定数据包的丢失(重复确认)而不用等到计时器超时,此时,发送端就认为网络处于拥塞状态。

快速恢复:

考虑到如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。
Tahoe:在认为网络处于拥塞状态之后。进行如下操作:(1)慢启动门限设置为当前拥塞窗口大小的一半,(2)把拥塞窗口设置为1,(3)重新进入慢启动状态
Reno:在认为网络处于拥塞状态之后。进行如下操作:(1)慢启动门限设置为当前拥塞窗口大小的一半,(2)把拥塞窗口设置为修改后的慢启动门限值,(3)进入拥塞避免状态

TCP Tahoe版本示意图
在这里插入图片描述
TCP Reno版本示意图
在这里插入图片描述

61、简述流量控制(滑动窗口rwnd)和拥塞控制(拥塞窗口cwnd)的相同点和区别。

同: 两者的现象都是丢包,实现机制都是让发送方发的慢一点,发的少一点。
异: 拥塞控制所要做的都有一个前提,就是网络能承受现有的网络负荷。流量控制往往指的是点对点通信量的控制,是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率,以便使接收端来得及接受。拥塞控制的丢包发生在路由器上,流量控制的丢包发生在接收端。

滑动窗口一般指接收窗口,接收器窗口是接收器可以获取数据包的缓冲区,用于流量控制,而拥塞窗口用于拥塞控制。TCP真正的发送窗口=min(rwnd,cwnd)

Quick and Quick! Salute!

猜你喜欢

转载自blog.csdn.net/Joel_wen/article/details/113447238