计算机网络常见面试题2

6、TCP/UDP

TCP/UDP都是是传输层协议,但是两者具有不同的特性,同时也具有不同的应用场景,下面以图表的形式对比分析。
在这里插入图片描述
面向报文
面向报文的传输方式是应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文。因此,应用程序必须选择合适大小的报文。若报文太长,则IP层需要分片,降低效率。若太短,会是IP太小。
面向字节流
面向字节流的话,虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲,当应用程序传送的数据块太长,TCP就可以把它划分短一些再传送。
TCP和UDP协议的一些应用
在这里插入图片描述
什么时候应该使用TCP?
当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。
什么时候应该使用UDP?
当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用UDP。

7、DNS?一次完整的HTTP请求所经历的步骤?

DNS(Domain Name System,域名系统),因特网上作为域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的IP数串。通过主机名,最终得到该主机名对应的IP地址的过程叫做域名解析(或主机名解析)。DNS协议运行在UDP协议之上,使用端口号53。
主机解析域名的顺序:A、浏览器缓存;B、找本机的hosts文件;C、路由缓存;D、找DNS服务器(本地域名、顶级域名、根域名)
Cookies 和Session的区别

  1. cookie是一种发送到客户浏览器的文本串句柄,并保存在客户机硬盘上,可以用来在某个WEB站点会话间持久的保持数据
  2. session其实指的就是访问者从到达某个特定主页到离开为止的那段时间。Session其实是利用Cookie进行信息处理的,当用户首先进行了请求后,服务端就在用户浏览器上创建了一个Cookie,当这个Session结束时,其实就是意味着这个Cookie就过期了
  3. cookie数据保存在客户端,session数据保存在服务器端
    比如:在浏览器中输入www.baidu.com后执行的全部过程:
    (1) 浏览器获取输入的域名www.baidu.com
    (2) 浏览器向DNS请求解析www.baidu.com的IP地址
    (3) 域名系统DNS解析出百度服务器的IP地址
    (4) 浏览器与该服务器建立TCP连接(默认端口号80)
    (5) 浏览器发出HTTP请求,请求百度首页
    (6) 服务器通过HTTP响应把首页文件发送给浏览器
    (7) TCP连接释放
    (8) 浏览器将首页文件进行解析,并将Web页显示给用户。
    涉及到的协议
    (1) 应用层:HTTP(WWW访问协议),DNS(域名解析服务)
    (2) 传输层:TCP(为HTTP提供可靠的数据传输),UDP(DNS使用UDP传输)
    (3) 网络层:IP(IP数据数据包传输和路由选择),ICMP(提供网络传输过程中的差错检测),ARP(将本机的默认网关IP地址映射成物理MAC地址)

8、IP首部?TCP首部?

IP首部:
在这里插入图片描述
1、第一个4字节(也就是第一行):
(1)版本号(Version),4位;用于标识IP协议版本,IPv4是0100,IPv6是0110,也就是二进制的4和6。
(2)首部长度(Internet Header Length),4位;用于标识首部的长度,单位为4字节,所以首部长度最大值为:(2^4 - 1) * 4 = 60字节,但一般只推荐使用20字节的固定长度。
(3)服务类型(Type Of Service),8位;用于标识IP包的优先级,但现在并未使用。
(4)总长度(Total Length),16位;标识IP数据报的总长度,最大为:2^16 -1 = 65535字节。
2、第二个四字节:
(1)标识(Identification),16位;用于标识IP数据报,如果因为数据链路层帧数据段长度限制(也就是MTU,支持的最大传输单元),IP数据报需要进行分片发送,则每个分片的IP数据报标识都是一致的。
(2)标识(Flag),3位,但目前只有2位有意义;最低位为MF,MF=1代表后面还有分片的数据报,MF=0代表当前数据报已是最后的数据报。次低位为DF,DF=1代表不能分片,DF=0代表可以分片。
(3)片偏移(Fragment Offset),13位;代表某个分片在原始数据中的相对位置。
3、第三个四字节:
(1)生存时间(TTL),8位;以前代表IP数据报最大的生存时间,现在标识IP数据报可以经过的路由器数。
(2)协议(Protocol),8位;代表上层传输层协议的类型,1代表ICMP,2代表IGMP,6代表TCP,17代表UDP。
(3)校验和(Header Checksum),16位;用于验证数据完整性,计算方法为,首先将校验和位置零,然后将每16位二进制反码求和即为校验和,最后写入校验和位置。
4、第四个四字节:源IP地址
5、第五个四字节:目的IP地址
TCP首部:
在这里插入图片描述
1、第一个4字节:
(1)源端口,16位;发送数据的源进程端口
(2)目的端口,16位;接收数据的进程端口
2、第二个4字节与第三个4字节
(1)序号,32位;代表当前TCP数据段第一个字节占整个字节流的相对位置;
(2)确认号,32位;代表接收端希望接收的数据序号,为上次接收到数据报的序号+1,当ACK标志位为1时才生效。
3、第四个4字节:
(1)数据偏移,4位;实际代表TCP首部长度,最大为60字节。
(2)6个标志位,每个标志位1位;
SYN,为同步标志,用于数据同步;ACK,为确认序号,ACK=1时确认号才有效;FIN,为结束序号,用于发送端提出断开连接;URG,为紧急序号,URG=1是紧急指针有效;PSH,指示接收方立即将数据提交给应用层,而不是等待缓冲区满;RST,重置连接。
(3)窗口值,16位;标识接收方可接受的数据字节数。详解可参看:http://www.cnblogs.com/woaiyy/p/3554182.html
4、第五个4字节
(1)校验和,16位;用于检验数据完整性。
(2)紧急指针,16位;只有当URG标识位为1时,紧急指针才有效。紧急指针的值与序号的相加值为紧急数据的最后一个字节位置。用于发送紧急数据。

9.TCP为什么是可靠的?

TCP的可靠保证,是它的三次握手双向机制,这一机制保证校验了数据,保证了他的可靠性。
1) 应用数据被分割成TCP认为最适合发送的数据块。
2) 确认机制,发送报文后,等待确认。
3) 重发机制,没有收到确认,将重发数据段。
4) 保持它首部和数据的校验和。确认数据的准确性。
5) 流量控制和拥塞控制。
1、确认和重传:接收方收到报文就会确认,发送方发送一段时间后没有收到确认就重传。
2、数据校验
3、数据合理分片和排序:
UDP:IP数据报大于1500字节(MTU).这个时候发送方IP层就需要分片.把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.TCP则会按MTU合理分片,接收方会缓存未按序到达的数据,重新排序后再交给应用层。
4、流量控制:当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。
5、拥塞控制:当网络拥塞时,减少数据的发送。

10、TCP建立与终止?为什么三次握手?为什么四次挥手?为什么等待2MSL?

三次握手:
在这里插入图片描述
四次挥手:
在这里插入图片描述
【问题1】描述三次握手?四次挥手?
答:TCP连接请求由客户端主动打开,服务器端被动打开连接。第一次握手:客户端向服务器端发送连接请求报文段,由于是请求连接,所以同步位SYN=1,并发送序号seq=x的数据。第二次握手:服务器端接收到连接请求,会对其返回一个请求连接确认,表示同意建立连接。由于这也是一个同步连接,所以同步位SYN=1;另外这是一个连接确认,所以确认ACK=1(它也表示确认号字段ack=x+1有效);而确认号ack=x+1,表示:我已正确接收你前x个序号的数据,请你下次发送第x+1个序号的数据;另外,自己发送序号seq=y的数据;第三次握手:称为对确认的确认,这也是一个连接确认,所以确认ACK=1,确认号ack=y+1,表示我成功接收你前y个序号的数据,并请你下次发送第y+1个序号的数据。另外,自己发送序号seq=x+1,表示我对第二次请求的响应,开始发送第x+1个序号的数据。至此,连接状态确立,开始进行数据传送。
数据传送完毕后,需要释放TCP连接。TCP连接释放可以由客户端或者服务器端发起。
假设由客户端发起连接释放。第一次挥手:由于是一个连接释放请求,说明客户端已经没有数据要发送了,所以置终止控制位FIN=1,另外发送序号seq=u的数据;第二次挥手:服务器端收到连接释放请求,但服务器端并不会立刻响应释放,因为我数据有可能还没传完,所以我需要继续发送数据,置发送确认ACK=1,确认号ack=u+1,表示我成功接收你前序号为u的数据,另外发送序号可以置seq=v;第三次挥手:服务器端发完数据,也开是发送释放连接,告诉客户端我数据发送完毕,所以置终止控制位FIN=1,置发送确认ACK=1,(因为客户端没有发送数据),所以确认号不变,仍为ack=u+1,另外自己发送序号seq=w;第四次挥手:客户端收到服务器端的连接释放请求后,进行最后的确认,置确认ACK=1,确认号ack=w+1,表示我成功接收你给我发的前w个序号的数据。另外发送序号seq=u+1,表示对第三次挥手的响应。至此,TCP连接并未彻底关闭,客户端还要再等待2MSL(最长报文段寿命)的时间,才算彻底释放连接。
【问题2】为什么三次握手?为什么四次挥手?
答:为什么客户端A还要在发送一次确认?这主要是为了防止已失效的连接请求报文突然又传送到了服务器端B,因而产生错误。分析:客户端A发送的第一个连接请求有可能在网络的某个结点长时间停留,导致服务器端B没有立马收到该连接请求,所以,这时候A就会重新发送连接请求,就会可能出现先发送的连接请求后到的情况,服务器端会对两次连接都进行响应,发送两次连接确认。如果没有第三次握手,也就是对确认的确认,客户端只会对第二个连接做出响应进行传输数据,对第一个连接确认不做任何处理,因为在客户端看来,我第一个发送的连接请求已经失效了,而且我要传送的数据在第二个连接里已经做了。而服务器端并不知道啊,这就会造成服务器端一直在等待客户端给他发数据,所以自己会一直打开连接,白白浪费资源。
为什么四次挥手:确保数据能够完成传输,但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
【问题3】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:第一、为了保证客户端A发送的最后一个ACK报文能够到达服务器端B;因为这个ACK报文有可能丢失。如果没有等待2MSL,服务器端就会因为没有收到最后的ACK报文,无法正常的进入关闭状态。
第二、为了防止已失效的连接请求报文突然又传送到了服务器端B;客户端A在发送完最后一个ACK报文段之后,再经过2MSL,就可以使本连接中所有的报文段都从网络中消失,这样就不会出现新的连接中有旧的连接请求报文的现象。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

11、TCP流量控制

如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时,B告诉了A:“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此,发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意,TCP的窗口单位是字节,不是报文段。假设每一个报文段为100字节长,而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK,小写ack表示确认字段的值ack。
在这里插入图片描述
从图中可以看出,B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ,第二次又减到了 rwnd = 100 ,最后减到 rwnd = 0 ,即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ,只有在ACK=1时确认号字段才有意义。
TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口控测报文段(携1字节的数据),那么收到这个报文段的一方就重新设置持续计时器。

12、TCP拥塞控制

拥塞:对资源的需求>可用资源;
1.慢开始和拥塞避免
发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去。但只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络中的分组数。
慢开始算法:当主机开始发送数据时,如果立即所大量数据字节注入到网络,那么就有可能引起网络拥塞,因为现在并不清楚网络的负荷情况。因此,较好的方法是 先探测一下,即由小到大逐渐增大发送窗口,也就是说,由小到大逐渐增大拥塞窗口数值。
通常在刚刚开始发送报文段时,先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后,把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ,可以使分组注入到网络的速率更加合理。
在这里插入图片描述
每经过一个传输轮次,拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过“传输轮次”更加强调:把拥塞窗口cwnd所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个字节的确认。
另,慢开始的“慢”并不是指cwnd的增长速率慢,而是指在TCP开始发送报文段时先设置cwnd=1,使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况),然后再逐渐增大cwnd。
为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限ssthresh状态变量。慢开始门限ssthresh的用法如下:
当 cwnd < ssthresh 时,使用上述的慢开始算法。
当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞控制避免算法。
拥塞避免
让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。
在这里插入图片描述
无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞(其根据就是没有收到确认),就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半(但不能小于2)。然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。
这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。
如下图,用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。
在这里插入图片描述
2.快重传和快恢复
快重传
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时才进行捎带确认。
在这里插入图片描述
接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。
显然,接收方不能确认M4,因为M4是收到的失序报文段。根据 可靠传输原理,接收方可以什么都不做,也可以在适当时机发送一次对M2的确认。
但按照快重传算法的规定,接收方应及时发送对M2的重复确认,这样做可以让 发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后,也还要再次发出对M2的重复确认。这样,发送方共收到了 接收方的四个对M2的确认,其中后三个都是重复确认。
快重传算法还规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3,而不必 继续等待M3设置的重传计时器到期。
由于发送方尽早重传未被确认的报文段,因此采用快重传后可以使整个网络吞吐量提高约20%。
快恢复
与快重传配合使用的还有快恢复算法,其过程有以下两个要点:
当发送方连续收到三个重复确认,就执行“乘法减小”算法,把慢开始门限ssthresh减半。
与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口cwnd现在不设置为1),而是把cwnd值设置为 慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。
在这里插入图片描述

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

进击的程序猿~

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值