面试常见问题总结(网络篇)

OSI七层模型、五层模型、TCP/IP四层模型

七层模型、五层模型、四层模型

OSI分层 (7层):物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

五层协议(5层):物理层、数据链路层、网络层、运输层、 应用层。

TCP/IP分层(4层):网络接口层、 网际层、运输层、 应用层。

OSI七层模型

OSI中的层 功能 TCP/IP协议族 数据单元 设备
应用层 文件传输,电子邮件,文件服务,虚拟终端 HTTP,FTP(File Transfer Protocol,文件传输协议),SMTP(Simple Mail Transfer Protocol,简单邮件传输协议),DNS(Domain Name System,域名系统,用于将域名解析成对应的IP地址),Telnet(远程登录) APDU
表示层 数据格式化,代码转换,数据加密 没有协议 PPDU
会话层 解除或建立与别的接点的联系 没有协议 SPDU
传输层 提供端对端的接口 TCP,UDP 段(segment)
网络层 为数据包选择路由 IP,ICMP(ping),RIP,OSPF,BGP,IGMP 包(packet) 路由器
数据链路层 传输有地址的帧以及错误检测功能 SLIP,CSLIP,PPP,ARP(Address Resolution Protocol,地址解析协议,IP地址解析成MAC地址),RARP(MAC地址解析成IP地址),MTU 帧(frame) 网桥,交换机
物理层 以二进制数据形式在物理媒体上传输数据 ISO2110,IEEE802。IEEE802.2 比特(bit) 中继器,集线器,网关

每一层的作用

物理层:通过媒介传输比特,确定机械及电气规范(比特Bit)

数据链路层:将比特组装成帧和点到点的传递(帧Frame)

网络层:负责数据包从源到宿的传递和网际互连(包Packet)

传输层:提供端到端的可靠报文传递和错误恢复(段Segment)

会话层:建立、管理和终止会话(会话协议数据单元SPDU)

表示层:对数据进行翻译、加密和压缩(表示协议数据单元PPDU)

应用层:允许访问OSI环境的手段(应用协议数据单元APDU)

应用层

常用的HTTP方法有哪些?

GET: 用于请求访问已经被URI(统一资源标识符)识别的资源,可以通过URL传参给服务器
POST:用于传输信息给服务器,主要功能与GET方法类似,但一般推荐使用POST方式。
PUT: 传输文件,报文主体中包含文件内容,保存到对应URI位置。
HEAD: 获得报文首部,与GET方法类似,只是不返回报文主体,一般用于验证URI是否有效。
DELETE:删除文件,与PUT方法相反,删除对应URI位置的文件。
OPTIONS:查询相应URI支持的HTTP方法。

GET方法与POST方法的区别

  1. get重点在从服务器上获取资源,post重点在向服务器发送数据;

  2. get传输数据是通过URL请求,以field(字段)= value的形式,置于URL后,并用”?”连接,多个请求数据间用”&”连接,如http://127.0.0.1/Test/login.action?name=admin&password=admin,这个过程用户是可见的;

    post传输数据通过Http的post机制,将字段与对应值封存在请求实体中发送给服务器,这个过程对用户是不可见的;

  3. Get传输的数据量小,因为受URL长度限制,但效率较高;

    Post可以传输大量数据,所以上传文件时只能用Post方式;

  4. get是不安全的,因为URL是可见的,可能会泄露私密信息,如密码等;
    post较get安全性较高;

  5. get方式只能支持ASCII字符,向服务器传的中文字符可能会乱码。
    post支持标准字符集,可以正确传递中文字符。

HTTP请求报文与响应报文格式

请求报文包含四部分:

  • 请求行(request line):包含请求方法、URI、HTTP版本信息
  • 请求头部(header)由“名/值”对组成,每行一对,名和值之间使用冒号分隔:accept、host、user-agent、accept-encoding、accept-language、cache-control、cookie、connection、accept-charset
  • 空行
  • 请求内容实体(请求数据):POST方法中与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
请求头 说明
Host 接受请求的服务器地址,可以是IP:端口号,也可以是域名
User-Agent 发送请求的应用程序名称,包括平台、引擎版本、浏览器版本号
Connection 指定与连接相关的属性,如Connection:Keep-Alive
Accept-Charset 通知服务端可以发送的编码格式
Accept-Encoding 通知服务端可以发送的数据压缩格式
Accept-Language 通知服务端可以发送的语言

响应报文包含四部分:

  • 状态行:包含HTTP版本、状态码、状态码的原因短语(文本描述)
  • 响应首部字段:cache-control、content-length、content-type、date、expires、p3p、server、set-cookie、statusx-content-type-options、x-xss-protection
  • 空行
  • 响应内容实体
响应头 说明
Server 服务器应用程序软件的名称和版本
Content-Type 响应正文的类型(是图片还是二进制字符串)
Content-Length 响应正文长度
Content-Charset 响应正文使用的编码
Content-Encoding 响应正文使用的数据压缩格式
Content-Language 响应正文使用的语言

常见的HTTP响应状态码

  • 200:请求被正常处理,响应成功
  • 204:请求被受理但没有资源可以返回
  • 206:客户端只是请求资源的一部分,服务器只对请求的部分资源执行GET方法,相应报文中通过Content-Range指定范围的资源。
  • 301:永久性重定向,搜索引擎将删除源地址,保留重定向地址
  • 302:临时重定向,重定向地址由响应头中的Location属性指定,由于搜索引擎的判定问题,较为复杂的URL容易被其它网站使用更为精简的URL及302重定向劫持
  • 303:与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,能通过GET方法重定向到另一个URI上
  • 304:发送附带条件的请求时,条件不满足时返回,与重定向无关,缓存文件并未过期,还可继续使用,无需再次从服务端获取
  • 307:临时重定向,与302类似,只是强制要求使用POST方法
  • 400:请求报文语法有误,服务器无法识别
  • 401:请求需要认证
  • 403:请求的对应资源禁止被访问,服务器接收到请求,但是拒绝提供服务(认证失败)
  • 404:服务器无法找到对应资源
  • 500:服务器内部错误
  • 503:服务器正忙

HTTP1.1版本新特性

  1. 默认持久连接节省通信量,只要客户端服务端任意一端没有明确提出断开TCP连接,就一直保持连接,可以发送多次HTTP请求
  2. 管线化,客户端可以同时发出多个HTTP请求,而不用一个个等待响应
  3. 断点续传原理

常见HTTP首部字段

  1. 通用首部字段(请求报文与响应报文都会使用的首部字段)
    • Date:创建报文时间
    • Connection:连接的管理
    • Cache-Control:缓存的控制
    • Transfer-Encoding:报文主体的传输编码方式
  2. 请求首部字段(请求报文会使用的首部字段)
    • Host:请求资源所在服务器
    • Accept:可处理的媒体类型
    • Accept-Charset:可接收的字符集
    • Accept-Encoding:可接受的内容编码
    • Accept-Language:可接受的自然语言
  3. 响应首部字段(响应报文会使用的首部字段)
    • Accept-Ranges:可接受的字节范围
    • Location:令客户端重新定向到的URI
    • Server:HTTP服务器的安装信息
  4. 实体首部字段(请求报文与响应报文的的实体部分使用的首部字段)
    • Allow:资源可支持的HTTP方法
    • Content-Type:实体主类的类型
    • Content-Encoding:实体主体适用的编码方式
    • Content-Language:实体主体的自然语言
    • Content-Length:实体主体的的字节数
    • Content-Range:实体主体的位置范围,一般用于发出部分请求时使用

HTTP的缺点与HTTPS

  1. 通信使用明文不加密,内容可能被窃听
  2. 不验证通信方身份,可能遭到伪装
  3. 无法验证报文完整性,可能被篡改。
  4. HTTPS就是HTTP加上加密处理(一般是SSL安全通信线路)+认证+完整性保护

简述一下三次握手和四次挥手的过程

预备知识(TCP头部)

TCP在IP数据报内的封装:

TCP头部:

8个1比特的标志字段:

CWR(Congestion Window Reduced 拥塞窗口缩小) :CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段,标志为 1 时,则通知对方已将拥塞窗口缩小;

ECE(ECN-Echo ECN回响) :若其值为 1 则会通知对方,从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1;

URG(urgent 紧急) :该位设为 1,表示包中有需要紧急处理的数据,对于需要紧急处理的数据,与后面的紧急指针有关;

ACK(acknowledgement 确认):该位设为 1,确认应答的字段有效,TCP规定除了最初建立连接时的 SYN 包之外该位必须设为 1;

PSH(push 传送):该位设为 1,表示需要将收到的数据立刻传给上层应用协议,若设为 0,则先将数据进行缓存;

RST(reset 重置连接):该位设为 1,表示 TCP 连接出现异常必须强制断开连接;

SYN(synchronous 用于初始化一个连接的同步序列号):用于建立连接,该位设为 1,表示希望建立连接,并在其序列号的字段进行序列号初值设定;

FIN(finish 结束):该位设为 1,表示今后不再有数据发送,希望断开连接。

ISN(Initial Sequence Number,初始序列号)

三次握手和四次挥手

确认号字段(也可简称为ACK号或ACK字段)包含的值是该确认号的发送方期待接收的下一个序列号,即最后被成功接收的数据字节的序列号+1

三次握手

  1. 一方主动发送SYN报文段(实际上是TCP头部的SYN标志字段置为了1的TCP/IP报文段)并在序列号位置置标志客户端的初始序列号ISN(c)(ISN是一个随机的数字),并指明自己想要连接的端口号,首先发送SYN报文段的这方称为客户端

  2. 服务端收到请求连接的SYN报文段后回复自己的SYN报文段作为响应,并在序列号位置置自己的初始序列号ISN(s),为了确认客户端的SYN,在ACK字段置ISN(c)+1表示下次想收到来自客户端数据报的序列号

  3. 为了确认服务端的SYN,客户端将ISN(s)+1作为ACK字段的数值,表示下次想收到来自服务端数据报的序列号,序列号是ISC(c)+1,表示这次发送的数据报的序列号是ISC(c)+1

四次挥手

以客户端要求主动请求关闭为例

  1. 客户端主动发送FIN报文段,并对上一次服务端发过来的数据报进行确认,自己的序列号为K,ACK字段为L,表示期望下一次客户端发来L号报文段
  2. 服务端收到客户端发来的FIN报文段之后发送ACK报文段回应,ACK=K+1表示已经收到K号报文段并期望下次客户端发来K+1号报文段,自己的序列号为L
  3. 服务端由被动变为主动要求关闭连接,发送FIN报文段,自己的序列号为P,仍然期望下次收到K+1号报文段
  4. 客户端收到服务端发送的FIN之后发送最后一次ACK报文表示已经收到了P号报文,ACK值为P+1,自己的序列号为K+1

连接的任何一方都能请求启动连接或者请求关闭连接

半关闭状态

TCP状态机

最后需要等待2MSL的原因

TIME_WAIT状态(2MSL等待状态)Maximum Segment Lifetime

一、保证TCP协议的全双工连接能够可靠关闭

二、保证这次连接的重复数据段从网络中消失

先说第一点,如果Client直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN,此时由于Client已经CLOSED了,就找不到与重发的FIN对应的连接,最后Server就会收到RST而不是ACK,Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失,但是却导致TCP协议不符合可靠连接的要求。所以,Client不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后正确的关闭连接。

再说第二点,如果Client直接CLOSED,然后又再向Server发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达Server,由于新连接和老连接的端口号是一样的,又因为TCP协议判断不同连接的依据是socket pair,于是,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。

  1. 等待2MSL的原因:以防最后一个ACK没有收到,服务端会重传FIN,直到最后一个ACK被收到
  2. 在2MSL等待时,服务端和客户端的连接端口都不可用。

解决方案:

  1. setsockopt中的SO_REUSEADDRSO_REUSEPROT可以在工业界解决等待2MSL

setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR,(const void *)&reuse , sizeof(int));

  1. 因为客户端的端口主机可以随机分配,但服务器使用的端口是固定的,所以尽量让客户端主动断开连接,让客户端进入TIME_WAIT状态。

从输入网址到显示网页的过程

  1. 客户端发起请求

  2. DNS域名解析,根 DNS 服务器–(com)–>顶级域 DNS 服务器–(baidu)–>权威 DNS 服务器

    顶级域 DNS 服务器主要负责诸如 com、org、net、edu、gov 等顶级域名。

    根 DNS 服务器存储了所有顶级域 DNS 服务器的 IP 地址,也就是说你可以通过根服务器找到顶级域服务器。

    例如:「www.baidu.com」,根服务器会返回所有维护 com 这个顶级域服务器的 IP 地址。然后你任意选择其中一个顶级域服务器,请求该顶级域服务器,该顶级域服务器拿到域名后应当能够做出判断并给出负责当前域的权威服务器地址,以百度为例的话,顶级域服务器将返回所有负责 baidu 这个域的权威服务器地址。于是你可以任意选择其中一个权威服务器地址,向它继续查询 「www.baidu.com」 的具体 IP 地址,最终权威服务器会返回给你具体的 IP 地址。

    每次通过 DHCP 动态获取 IP 地址的时候,路由器不仅给你返回了 IP 地址,还会告诉你一个 DNS 服务器地址,这个就是你的本地 DNS 服务器地址,也就是说,你的所有域名解析请求只要告诉它就行了,它会帮你查并返回结果给你的。除此之外,本地 DNS 服务器往往是具有缓存功能的,通常两天内的记录都会被缓存,所以大部分时候你是感觉不到域名解析过程的,因为往往就是从缓存里拿的,非常快。

    主机向负责自己的本地 DNS 发送查询报文:

    ①:如果本地服务器缓存中有,将直接返回结果

    ②:本地服务器发现缓存中没有,于是从内置在内部的根服务器列表中选一个发送查询报文

    ③:根服务器解析一下后缀名,告诉本地服务器负责 .com 的所有顶级服务器列表

    ④:本地服务器选择一个顶级域服务器继续查询,.com 域服务器拿到域名后继续解析,返回负责 .xx 域的所有权威服务器列表

    ⑥:本地服务器从返回的权威服务器之一再次发送查询报文,最终会从某一个权威服务器上得到具体的 IP 地址

    ⑧:向主机返回结果

  3. 发起TCP的三次握手

  4. 建立TCP连接后发起http请求

  5. 服务器响应http请求,浏览器得到html代码

  6. 浏览器解析html代码,并请求html代码中的资源(如JavaScript、css、图片等)

  7. 浏览器对页面进行渲染呈现给用户

TCP与UDP的区别

  1. TCP协议是有连接的,有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接,会话结束之后通过四次挥手结束连接。而UDP是无连接的
  2. TCP协议保证数据按序发送,按序到达,提供超时重传来保证可靠性,但是UDP不保证按序到达,甚至不保证到达,只是努力交付,即便是按序发送的序列,也不保证按序送到。
  3. TCP有流量控制和拥塞控制,而UDP没有,所以UDP即使网络拥堵客户端的发送速率也不会有影响
  4. TCP协议所需资源多,TCP首部需20个字节(不算可选项),UDP首部字段只需8个字节。
  5. TCP只支持一对一通信,而UDP支持一对一,一对多,多对多通信
  6. TCP是面向字节流,可靠的服务,UDP是面向报文,不可靠的服务
  7. TCP注重数据安全性,UDP数据传输快,因为不需要连接等待,少了许多操作,但是其安全性却一般
谢谢小天使请我吃糖果
0%