OSI七层模型
OSI七层模型一般指开放系统互连参考模型 (Open System Interconnect 简称OSI)是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的开放系统互连参考模型,为开放式互连信息系统提供了一种功能结构的框架。
具体如下:
-
应用层:各种应用程序协议,比如 HTTP、HTTPS、FTP、SOCKS 安全套接字协议、DNS 域名系统、GDP 网关发现协议等。
-
表示层:加密解密、转换翻译、压缩解压缩,比如 LPP 轻量级表示协议。
-
会话层:不同机器上的用户建立和管理会话,比如 SSL 安全套接字层协议、TLS 传输层安全协议、RPC 远程过程调用协议等。
-
传输层:接收上一层的数据,在必要的时候对数据进行分割,并将这些数据交给网络层,保证这些数据段有效到达对端。比如TCP传输控制协议、UDP用户数据协议。
-
网络层:控制子网的运行:逻辑编址、分组传输、路由选择,比如 IP、IPV6、SLIP 等等。路由器工作在网络层。
-
数据链路层:物理寻址,同时将原始比特流转变为逻辑传输路线,比如 XTP 压缩传输协议、PPTP 点对点隧道协议等等。交换机工作在数据链路层。
-
物理层:机械、电子、定时接口通信信道上的原始比特流传输,比如 IEEE802.2 等等,会尽可能屏蔽传输媒介和通信手段的差异。
下面这张图详细将OSI七层模型详细地进行了总结(图片来源于网络),供同学们参考。
传输控制协议 TCP
传输控制协议-TCP:TCP是面向连接的、可靠的、基于字节流的传输层通信协议,它将应用层的数据流分割成报文段并发送给目标节点的TCP层。数据包都有序号,对方收到则发送ACK确认,未收到则重传。TCP使用奇偶校验和来检验数据在传输过程中是否有误,在发送和接收时都要计算校验和。
TCP/IP四层网络模型
TCP/IP协议被组织成四个概念层,其中有三层对应于OSI参考模型中的相应层。TCP/IP协议族并不包含物理层和数据链路层,因此它不能独立完成整个计算机网络系统的功能,必须与许多其他的协议协同工作。 TCP/IP分层模型的四个协议层分别完成以下的功能:
- 网络接口层:网络接口层包括用于协作IP数据在已有网络介质上传输的协议,如ARP,RARP。
- 网际层:网际层对应OSI七层参考模型的网络层。负责数据的包装、寻址和路由。同时还包含网际控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息(常见的Ping命令)。
- 传输层对应OSI七层参考模型的传输层,它提供两种端到端的通信服务。其中TCP协议(Transmission Control Protocol)提供可靠的数据流运输服务,UDP协议(User Datagram Protocol)提供不可靠的用户数据报服务。
- 应用层对应OSI七层参考模型的应用层和表示层。
TCP协议的三次握手🤝(重点)
第一次握手:客户端发送SYN包(syn=x)到服务器,并进入SYN_SEND状态,等待服务器确认;
第二次握手:服务器收到SYN包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP连接都将被一直保持下去。
三次握手流程图如下:
为什么是三次握手?(不能是两次握手吗?)
答:第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。客户端发送的连接请求可能会在网络中滞留,可能导致很长一段时间后才能收到服务器发回的ACK信息。若超过客户端的超时重传时间后,客户端就会重新请求连接。之前发送的滞留的连接请求最后还是会到达服务器,如果没有第三次握手,服务器就会打开两个连接。如果有第三次握手,客户端就会忽略服务器之后发送的对滞留连接请求的连接确认,服务器也就不会再次打开连接。
首次握手存在什么安全隐患?
答:SYN超时机制可能导致SYN Flood攻击。因为服务器收到客户端的SYN,回复SYN-ACK时没有收到ACK确认,服务器会不断进行重试直至超时,Linux默认等待63秒才断开连接,攻击者可能利用此机制发动SYN洪水,不断建立连接后断开,造成SYN队列满,让正常连接无法得到处理。
SYN Flood防护措施:SYN队列满后,通过tcp_syncookies参数回发SYN Cookie,若是正常连接则客户端会发回SYN Cookie,直接建立连接,而非法连接则不会。
建立连接后客户端出现故障怎么办?
答:TCP设有保活机制。在keep alive time即保活时间内,开启保活功能的一端将向对方发送保活探测报文,如果未收到响应则继续发送。当尝试次数达到保活探测数时若仍未收到响应则中断连接。
TCP协议的四次挥手👋🏻(重点)
与建立连接的“三次握手”类似,断开一个TCP连接则需要“四次握手”。
第一次挥手:客户端发送释放连接的报文FIN,用来关闭客户端到服务器的数据传送。
第二次挥手:服务器收到客户端发送的FIN,发回客户端确认报文ACK,此时ACK=1,确认序号为收到的序号+1。此时,TCP连接处于半关闭状态。即服务器进入CLOSE_WAIT状态。
第三次挥手:服务器不再需要连接时,发送释放连接报文FIN给客户端,此时FIN=1,ACK=1。关闭与客户端的数据传送,服务器进入LAST_ACK状态。
第四次挥手:客户端收到后发出确认,ACK=1,确认序号为收到序号+1,并进入TIME-WAIT状态,等待2MSL(最大报文存活时间)后释放连接。服务器端收到客户端的确认信息后立即释放连接。
为什么是四次挥手?
答:因为全双工通信发送方和接收方都需要FIN报文和ACK报文。客户端发送了FIN释放连接报文后,服务器收到了这个报文,进入CLOSE-WAIT状态。这个状态是为了让服务器发送还未发送完成的数据,发送完毕后,服务器会发送FIN释放了连接报文。
为什么还要等待2MSL后才释放连接?
答:
-
确保有足够的时间让对方收到ACK包。如果服务器没收到客户端发送来的确认报文,就会重新发送释放连接报文,客户端等待2MSL就是为了处理这种情况的发生。
-
可以避免新旧链接混淆。等待2MSL可以让该连接时间段内产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文。
服务器出现大量CLOSE_WAIT的原因是什么?怎么办?
答:可能是对方关闭Socket连接,我方忙于读或写,没有及时关闭连接。解决方法:检查代码,特别是释放资源的代码;检查配置,特别是处理请求的线程配置。
TCP如何保证可靠传输?
-
发送方给每个包进行编号,接收方对数据包进行排序,再把有序数据交付给应用层。
-
TCP会保持首部和数据的校验和,目的是检测数据在传输过程中的变化,如果检验和有差错,TCP将丢弃这个报文段且不确认收到此报文段。
-
发送方每发完一个报文段就停止发送,等待接收方确认。收到接收方的确认后再发下一个报文段;如果不能及时收到确认,将发送方重发这个报文段。
-
流量控制:当接收方来不及处理发送方的数据,就会提示发送方降低发送速率。TCP利用滑动窗口实现流量控制。
-
拥塞控制:当网络拥塞时,会减少数据的发送。
TCP的滑动窗口
TCP使用滑动窗口做流量控制与乱序重排。发送方和接收方各有一个窗口,接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。如果发送窗口左部的字节已经发送并且收到了确认,那么就将发送窗口向右滑动一定距离,直到左部第一个字节不是已发送并且已确认的状态;接受窗口的滑动类似,接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口。接收窗口只会对窗口内最后一个按序到达的字节进行确认。发送方得到一个字节的确认后,就知道这个字节之前的所有字节都已经被接收。
TCP的拥塞控制
如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,导致网络拥塞程度更高。因此,当出现拥塞时,应当控制发送方的速率。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。TCP主要通过四个算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。
慢开始和拥塞避免
慢开始让拥塞窗口大小为1,收到确认后,会将窗口大小翻倍(2,4,8...)慢开始有一个限制ssthresh,当拥塞窗口大小 >= ssthresh的一半时,会进入拥塞避免。
在拥塞避免中,ssthresh每次收到确认后不再是翻倍,而是+1。如果出现了超时,则ssthresh将设置为当前拥塞窗口的一半,然后重新执行慢开始。
快重传和快恢复
接收方会对最后一个收到的有序报文段进行确认。例如已经接收到M 1和M 2,此时收到M 4,应当发送对M 2的确认。发送端如果收到了三个重复的确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到3个M 2,则M 3丢失,立即重传M 3。在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复:拥塞窗口大小设置为原来的一半,然后不再执行慢开始,直接进入拥塞避免。
用户数据报协议-UDP
UDP即用户数据报协议,是一个无连接的简单的面向数据报的传输层协议。UDP面向非连接,不维护连接状态,支持同时向多个客户端传输相同的信息。由于其数据报头只有8个字节所以额外开销较小。吞吐量只受限于数据生成速率、传输速率以及机器性能。UDP会尽最大努力交付,但不保证可靠交付,无需维持复杂的链接状态表。它是面向报文的,不对应用程序提交的报文信息进行拆分或合并。
TCP和UDP的区别
它们的区别如下:
- TCP提供面向连接、可靠的数据传输服务;UDP提供无连接、最大努力的数据传输服务。
- TCP 主要提供完整性服务,UDP 主要提供及时性服务。
- UDP支持一对一,一对多,多对一,多对多;TCP只支持一对一。
- UDP不具备有序性,TCP可保证有序性。
超文本传输协议-HTTP
HTTP(HyperText Transfer Protocol),即超文本传输协议。是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是为 Web 浏览器与 Web 服务器之间的通信而设计的,但也可以用于其他目的。它基于 TCP/IP 通信协议来传递数据(HTML 文件、图片文件、查询结果等)。
输入URL后会发生什么(重点)
-
DNS解析:浏览器会根据URL逐层查询DNS缓存,解析URL的域名所对应的IP地址。
注:DNS缓存由近到远依次是:浏览器缓存->系统缓存->路由器缓存->IPS服务器缓存->根域名服务器缓存->顶级域名服务器缓存。
-
建立TCP连接:找到IP地址后,会根据IP地址和对应的端口(默认80),和服务器通过三次握手建立TCP连接。
-
发送HTTP请求:浏览器会给服务器发送读取文件的HTTP请求。
-
服务器响应:服务器对浏览器请求作出响应,并把带有HTML文本的HTTP响应报文发送给浏览器。
-
浏览器解析渲染页面:浏览器收到HTML并在视窗内进行渲染。
-
连接结束:浏览器和服务器通过四次挥手释放TCP连接。
第5步和第6步没有先后顺序。
常见的HTTP状态码
- 1xx: 提示信息,表示请求已被接收,继续处理。
- 2xx: 成功,表示请求已被成功接收,理解,接受。
- 3xx: 重定向,要完成请求必须进行进一步操作。
- 4xx: 客户端错误,请求有格式错误或请求无法实现。
- 5xx: 服务端错误,服务器未能响应合法请求。
状态码 | 解释 |
---|---|
200 OK | 正常返回 |
400 Bad Request | 客户端请求有格式错误,不能被服务器所理解 |
401 Unauthorized | 请求未经授权,这个状态码必须和WWW-Authenticate报头域一起使用 |
403 Forbidden | 服务器收到请求,但拒绝提供服务 |
404 Not Found | 请求资源不存在(输入错误的URL) |
500 Internal Server Error | 服务器内部错误 |
503 Server Unavailable | 服务器当前不能处理客户端请求,一段时间后可能恢复正常 |
GET请求和POST请求的区别(基础但很重要)
- HTTP报文层面:GET将请求信息放在URL,浏览器会对URL长度进行限制;POST将信息放在报文体中,大小无限制。
- 数据库层面:GET作为查询请求,每次执行得到的结果都相同,且不会修改数据,因此符合幂等性和安全性;POST会往数据库中提交数据,不符合幂等性和安全性。
- 其他层面:GET请求可以被浏览器记录,可以被缓存和存储,POST请求不行。
Cookie和Session
Cookie
Cookie是由服务器发送给客户端的特殊信息,以文本的形式存放在客户端。客户端再次请求时,会把Cookie回发。服务器接收到后,会解析Cookie生成与客户端相对应的内容。
Session
Session是服务端的机制,在服务端保存的信息。解析客户端请求并操作session id,并按需保存状态信息。
Cookie和Session的区别
- 数据存放位置不同:Cookie数据存放在客户的浏览器上,Session数据放在服务器上。
- 安全程度不同:Cookie并不安全,攻击者可以分析存放在本地的Cookie,可能会带来安全问题。Session是相对安全的。
- 性能差别:Session会在其生命周期内保存在服务器上。当访问量增加,会占用服务器的性能,可使用Cookie减轻服务器性能开销。
- 数据存储大小不同:单个Cookie保存的数据不能超过4KB,许多浏览器都限制一个站点最多保存20个Cookie。而Session则存储于服务端,不受浏览器限制。
HTTPS
HTTPS(全称:Hyper Text Transfer Protocol over SecureSocket Layer),它是以安全为目标的 HTTP 通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础上加入SSL,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。
什么是SSL?
SSL(Security Sockets Layer),即安全套阶层,它是为网络通信提供安全及数据完整性的一种安全协议,SSL3.0后改名为TLS,采用身份验证和数据加密来保证网络通信的安全和数据的完整性。
SSL 加密方式
- 对称加密:加密和解密都使用同一个密钥。
- 非对称加密:加密使用的密钥和解密使用的密钥是不相同的。(公钥和私钥)
- 哈希算法:将任意长度的信息转换为固定长度的值,算法不可逆。
- 数字签名:证明某个消息或者文件是某人发出/认同的。
HTTPS数据传输流程
- 浏览器将支持的加密算法信息发送给服务器。
- 服务器选择一种浏览器支持的算法,以证书的形式回发给浏览器。
- 浏览器检查证书的合法性,并用证书中的公钥对随机生成的消息进行加密。
- 服务器用自己的私钥解密消息,确定密码,验证哈希,并加密响应消息回发给浏览器。
- 浏览器解密响应消息,如果跟之前发过去的哈希值一致,那么之后都使用之前生成的随机密码加密。
HTTPS的加密过程
- 服务器拥有CA证书的公钥和私钥;
- 浏览器向服务器发送请求,服务器将证书公钥传输给浏览器;
- 浏览器验证证书有效后,随机生成一个密钥,再用公钥加密后传给服务器;
- 服务器收到后用私钥解密可以得到这个密钥;
- 这样浏览器和服务器双方都有密钥,之后双方所有的数据都通过密钥加密解密就行。
有了CA证书,可以避免中间人攻击,浏览器可以确保收到的公钥一定是请求网站发过来的。
HTTP和HTTPS的区别
- HTTP需要到CA申请证书,HTTP不需要。
- HTTPS密文传输,HTTP明文传输。
- 连接方式不同,HTTPS默认使用443端口,HTTP使用80端口。
- HTTPS = HTTP + 加密 + 认证 + 完整性保护,较HTTP安全。
Socket 套接字
Socket是对TCP/IP协议的抽象,是操作系统对外开放的接口,它封装了一系列网络操作的API。
Socket的通信流程如下图所示:
Socket面试中问得较少,但也可能被问到,建议同学们亲自动手编写一个demo来实现服务器和客户端的socket通信。