1. 计算机网络体系结构
OSI七层体系结构、TCP/IP四层体系结构
OSI:Open Systems Interconnection Reference Model,开放系统互连基本参考模型 OSI/RM
两种体系结构的区别
- OSI采用七层模型,TCP/IP是四层模型。
- TCP/IP的网络接口层没有真正的定义,只是概念性的描述。而OSI把它分为2层,每一层功能详尽。
- 在协议开发之前,就有了OSI模型,所以OSI模型具有共通性,而TCP/IP是基于协议建立的模型,不适用于非TCP/IP的网络。
- 实际应用中,OSI模型是理论上的模型,没有成熟的产品;而TCP/IP已经成为国际标准。
2. TCP三次握手和四次挥手
首先,介绍一下几个概念:
- SYN:同步位,连接标识,1表示建立连接
- ACK:确认位,确认标识,1表示确认
- FIN:终止控制位,关闭连接标识,1表示关闭连接
- seq number:序号,占32位,用来标识从源端向目的端发送的字节流,发起方发送数据时对此进行标记。seq 的初始值是一个随机数,会根据发送的报文段来决定是否需要 +1。SYN 报文段不能携带数据,但要消耗掉一个序号。ACK 报文段可以携带数据,但如果不携带数据则不消耗序号。
- ack number:确认号,占32位,只有 ACK 为1时,确认号字段才有效。ack = seq + 1。
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开,另一方被动打开。
握手之前,客户端A 会结束 CLOSED(关闭)状态,然后就可以发送连接请求报文段。而 服务器B 也会结束 CLOSED 状态,然后进入 LISTEN(收听)状态,准备接受 客户端A 的连接请求。随后就可以开始三次握手:
- A 向 B 发送连接请求报文段,首部中的同步位 SYN = 1,同时选择一个初始序号 seq = x。这时,A 进入 SYN-SENT(同步已发送)状态。
- B 收到连接请求报文段后,如同意建立连接,则向 A 发送确认。在确认报文段中,应把 SYN 和 ACK 都置1,确认号是 ack = x + 1,同时也为自己选择一个初始序号 seq = y。这时,B 进入 SYN-RCVD(同步收到)状态。
- A 收到 B 的确认后,还要向 B 发送确认。确认报文段的 ACK 置1,确认号是 ack = y + 1,而自己的序号 seq = x + 1。TCP 的标准规定,ACK 报文段可以携带数据,但如果不携带数据则不消耗序号,在这种情况下,下一个数据报文段的序号仍是 seq = x + 1。这时,TCP 连接已经建立,A 进入 ESTABLISHED (已建立连接)状态。当 B 收到 A 的确认后,也进入到 ESTABLISHED 状态。
数据传送阶段:握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。
从图中可以看出,建立连接经历了三次握手。数据传输结束后,通信的双方都可以释放连接。如果要释放连接,则需要经历四次挥手:
- A 先向 B 发送连接释放报文段,并停止再发送数据,把连接释放报文段首部的终止控制位 FIN 置 1,其序号 seq = u,它等于前面已传送过的数据的最后一个字节的序号 +1。这时,A 进入 FIN-WAIT-1(终止等待1)状态。
- B 收到连接释放报文段后即发出确认, 确认位ACK 置1,确认号是 ack = u + 1,序号是 seq = v,它等于 B 前面已传送过的数据的最后一个字节的序号 +1。这时,B 进入 CLOSE-WAIT(关闭等待)状态。并且从 A 到 B 这个方向的连接就释放了,此时的 TCP 连接处于半关闭状态,即 A 已经没有数据要发送了,但 B 若发送数据,A 仍要接收。也就是说,从 B 到 A 这个方向的连接并未关闭,这个状态可能会持续一段时间。A 收到来自 B 的确认后,就进入 FIN-WAIT-2(终止等待2)状态,等待 B 发出的连接释放报文段。
- 若 B 已经没有要向 A 发送的数据,则可以释放连接了。这时 B 发出的连接释放报文段必须是 FIN = 1,现假定 B 的序号为 seq = w(在半关闭状态 B 可能有发送了一些数据)。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态,等待 A 的确认。
- A 在收到 B 的连接释放报文段后,必须对此发出确认。在确认报文段中把 ACK 置1,确认号 ack = w + 1,而自己的序号是 seq = u + 1。然后进入到 TIME-WAIT(时间等待)状态。A 要等待 2MSL(2个最长报文段寿命)后,才会进入到 CLOSED 状态。而当 B 收到 A 的确认后,也进入到 CLOSED 状态。
3. 为什么会采用三次握手?若采用二次握手可以吗?
采用三次握手是为了防止已失效的连接请求报文段突然又传送到主机B,因而产生错误。
已失效的连接请求报文段是指:主机A发出的连接请求没有收到主机B的确认,于是经过一段时间后,主机A又重新向主机B发送连接请求,且建立成功,顺利完成数据传输。考虑这样一种特殊情况,主机A第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到主机B,主机B以为是主机A又发起的新连接,于是主机B同意连接,并向主机A发回确认,但是此时主机A根本不会理会,主机B就一直在等待主机A发送数据,导致主机B的资源浪费。
采用两次握手不行,原因就是上面说的失效的连接请求的特殊情况。
4. 为什么TCP协议终止连接要四次?
为了保证通信双方都能够确认对方都已经确认自己的连接释放报文段。
- 当主机A确认发送完数据且知道B已经接收完了,想要关闭发送数据口(当然确认信号还是可以发),就会发FIN给主机B。
- 主机B收到A发送的FIN,表示收到了,就会发送ACK回复。
- 但这时B可能还在发送数据,没有想要关闭数据口的意思,所以FIN与ACK不是同时发送的,而是等到B数据发送完了,才会发送FIN给主机A。
- A收到B发来的FIN,知道B的数据也发送完了,回复ACK, A等待2MSL以后,没有收到B传来的任何消息,知道B已经收到自己的ACK了,A就关闭连接,B也关闭连接了。
5. 为什么 A 在 TIME-WAIT 状态必须等待 2MSL 的时间呢?
- 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失,因而使处于 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN + ACK 报文段,而 A 就能在 2MSL 时间内收到这个重传的 FIN + ACK 报文段。接着 A 重传一次确认,重新启动 2MSL 计时器。最后,A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间,而是在发送完 ACK 报文段后立即释放连接,那么就无法收到 B 重传的 FIN + ACK 报文段,因而也不会再发送一次确认报文段。这样,B 就无法按照正常步骤进入 CLOSED 状态。
- 防止“已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后,再经过 2MSL ,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
6. TCP(传输控制协议)与UDP(用户数据报协议)的区别
- TCP是面向连接的,UDP是无连接的
- TCP提供可靠交付的服务(数据正确性和顺序),UDP不保证可靠交付(丢包、不保证顺序)
- TCP是面向字节流的,常用于传输大量数据,UDP是面向报文的,常用于传输少量数据
- TCP有拥塞控制,而UDP没有
- UDP支持一对一、一对多、多对一和多对多的交互通信,而TCP只支持一对一的交互通信
- UDP的首部开销小,只有8个字节,而TCP 的首部至少需要20个字节
7. 面向连接和非面向连接(无连接)的服务的特点是什么?
面向连接的服务,通信双方在进行通信之前,要先在双方建立起一个完整的可以彼此沟通的通道,在通信过程中,整个连接的情况一直可以被实时地监控和管理。
非面向连接的服务,不需要预先建立一个联络两个通信节点的连接,需要通信的时候,发送节点就可以往网络上发送信息,让信息自主地在网络上去传,一般在传输的过程中不再加以监控。
8. HTTP和HTTPS的区别
- HTTP是超文本传输协议,信息采用明文传输,HTTPS则是具有安全性SSL加密传输协议
- HTTPS协议需要到CA申请证书,大多数情况下需要一定费用
- HTTP和HTTPS默认端口号不一样,HTTP是80端口,HTTPS是443端口
- HTTP连接是无状态的,而HTTPS采用HTTP+SSL构建可进行加密传输、身份认证的网络协议,更安全。(无状态,指的是不具备保存之前发送过的请求或响应的功能,每一次请求都是独立无关的)
- HTTP建立连接的过程比HTTPS快。因为HTTP除了TCP三次握手,还要经过SSL握手。连接建立之后数据传输速度,二者无明显区别
9. HTTPS的连接过程
- 客户端向服务器发送请求,并传送客户端 SSL 协议的版本号,加密算法的种类,产生的随机数,以及其他服务器和客户端之间通讯所需要的各种信息。
- 服务器向客户端传送 SSL 协议的版本号,加密算法的种类,随机数以及其他相关信息,同时服务器还将向客户端传送自己的证书。
- 客户端利用服务器传过来的信息验证服务器的合法性,服务器的合法性包括:证书是否过期,发行服务器证书的 CA 是否可靠,发行者证书的公钥能否正确解开服务器证书的 “发行者的数字签名”,服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过,通讯将断开;如果合法性验证通过,将继续进行第4步。
- 用户端随机产生一个用于通讯的 “对称密码”,然后用服务器的公钥(服务器的公钥从 步骤2 中的服务器的证书中获得)对其加密,然后将加密后的“预主密码”传给服务器。
- 如果服务器要求客户的身份认证(在握手过程中为可选),用户可以建立一个随机数然后对其进行数据签名,将这个含有签名的随机数和客户自己的证书以及加密过的密钥一起传给服务器。
- 如果服务器要求客户的身份认证,服务器必须检验客户证书和签名随机数的合法性,具体的合法性验证过程包括:客户的证书使用日期是否有效,为客户提供证书的 CA 是否可靠,发行 CA 的公钥能否正确解开客户证书的发行 CA 的数字签名,检查客户的证书是否在证书废止列表(CRL)中。检验如果没有通过,通讯立刻中断;如果验证通过,服务器将用自己的私钥解开加密的私钥,然后执行一系列步骤来产生主通讯密码(客户端也将通过同样的方法产生相同的主通讯密码)。
- 服务器和客户端用相同的对称加密密钥,对称密钥用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性,防止数据通讯中的任何变化。
- 客户端向服务器端发出信息,指明后面的数据通讯将使用的 步骤7 中的主密码为对称密钥,同时通知服务器客户端的握手过程结束。
- 服务器向客户端发出信息,指明后面的数据通讯将使用的 步骤7 中的主密码为对称密钥,同时通知客户端服务器端的握手过程结束。
- SSL 的握手部分结束,SSL 安全通道的数据通讯开始,客户和服务器开始使用相同的对称密钥进行数据通讯,同时进行通讯完整性的检验。
10. HTTPS 是如何保证数据传输的安全性的?
HTTPS是利用非对称加密、对称加密和数字证书来保证数据传输的安全性的。
非对称加密的公钥是放在数字证书里面的。
服务器在给客户端传输公钥的过程中,会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。
为了防止信息摘要被人调换,服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。
最后还会把原来没Hash算法之前的个人信息、公钥和数字签名合并在一起,形成数字证书。
当客户端拿到这份数字证书之后,就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要,然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比,如果一样,则证明所拿到的公钥是服务器的,否则就不是。如图:
然后客户端生成一个对称加密的密钥,然后用服务器的公钥进行加密,传给服务器。服务器拿到后,使用私钥解密,就得到了客户端的对称加密密钥。然后就利用密钥对传输数据进行加密,进行传输。
11. GET和POST的区别
- 从缓存的角度上说,GET会被浏览器主动缓存下来,留下历史记录,但是POST不会。
- 从编码的角度上说,GET只能进行URL编码,它只能接收ASCII字符,但是POST没有限制。
- 从参数的角度上说,GET一般放在URL上传递参数,POST放在请求体里,更适合传递敏感信息。
- 从幂等的角度上说,GET是幂等的,而POST不是。
- 从数据大小的角度上说,GET提交的数据大小有限制(因为浏览器对URL的长度有限制),而POST方法提交的数据没有限制。
- 不过据我了解的,其实GET和POST本质上都是TCP连接,并无差别。但是由于HTTP的规定和浏览器/服务器的限制,导致它们在应用过程中体现出一些不同。
- 还有可以从TCP的角度上说,GET请求会把请求报文一次性发出去,但是POST会分为两个TCP数据包。首先发送的是header部分,若是服务器响应100(continue),则会发送body部分,当然「火狐」浏览器除外,它的 POST 请求只发一个 TCP 包。
PS:幂等是什么?如果一个方法重复执行多次,产生的效果是一样的,那么这个方法就是幂等的。「它本质上意味着成功执行请求的结果与其执行次数无关。」
这时候面试官可能还会追加着问你:既然POST要分为两个TCP数据包发送,那GET是不是会比POST更有效啊!你可以这样回答:
- 首先,GET和POST都有它们自己的语义的,最好不要混用。
- 另外,虽然说POST会分为两个数据包发送,但是其实在网络条件好的情况下,发一次包和发两次包的相差的时间基本可以被无视了。并且在网络条件差的情况下,两次包的TCP在验证数据包的完整性上还有更大的优点。
- 再者,也并不是所有的浏览器的POST请求都会发送两次TCP数据包的,比如火狐就不会。
12. 浏览器输入一个URL,按下回车网络传输的流程?
- DNS域名解析,得到IP地址
- 解析出IP地址后,根据IP地址和默认端口80和服务器建立连接
- 浏览器发出读取文件(URL中域名后边部分对应的文件)的HTTP请求,该请求报文作为TCP三次握手的第三个报文的数据发送给服务器
- 服务器对浏览器的请求作出响应,并把对应的html文本发送给浏览器
- 释放TCP连接(四次挥手断开连接)
- 浏览器解析该HTML文本并显示内容
DNS解析流程:
- 在主机查询DNS缓存,如果没有就会给本地的DNS发送查询请求
- 本地的DNS服务器向根域名服务器发送查询请求,根域名服务器返回该域名的一级域名服务器
- 该本地服务器给该一级域名服务器发送查询请求,然后依次类推直到查询到该域名的IP地址
过程中用到的协议以及作用
- 域名解析用到DNS协议
- DNS服务器是基于UDP的,因此会用到UDP协议
- 得到IP地址后,浏览器会与服务器建立HTTP连接,用到HTTP协议
- http协议生成GET请求报文,将该报文传给TCP层处理,用到了TCP协议
- 如果用到了HTTPS协议还会对HTTP协议内容进行加密
TCP层若有需要会对HTTP数据报分片,分片依据路径MTU和MSS
- TCP的数据报会发送给IP层,用到IP协议
- IP层通过路由选择,将数据发送给目的端口
- 以太网协议需要知道目的IP的物理地址,需要用到ARP协议
用到了网络中的哪些层,每一层的作用
① DNS协议,HTTP协议,HTTPS协议属于应用层
应用层是体系结构中的最高层。应用层确定进程之间通信的性质满足用户的需要。这里所说的进程就是指正在运行的程序。应用层不仅需要提供应用进程需要的信息交换,而且还要作为相互作用的应用进程的用户代理,来完成一些为进行语义上有意义的交换所必须的功能。
② TCP/UDP属于传输层
传输层的任务就是负责主机中两个进程间的通信。因特网的传输层可使用两种不同的协议;即面向连接的传输控制协议TCP和无连接的用户数据报协议UDP。面向连接的服务能够提供可靠的交付,两种方式都各有其优点
③ IP协议和ARP协议属于网络层
网络层负责为分组交换网上的不同主机提供通信。在发送数据时,网络层将传输层产生的报文段或用户数据报封装成分组或者包进行传送。在TCP/IP体系中,分组也叫作IP数据报。网络层的另一个任务就是选择合适的路由,使源主机传输层传下来的分组能够交付到目的主机。
④ 数据链路层
当发送数据时,数据链路层的任务是将在网络层交下来的IP数据报组装成帧,在两个相邻节点间的链路上传送以帧为单位的数据。每一帧包括数据和必要的控制信息(如同步信息、地址信息、差错控制以及流量控制等信息)。控制信息使接收端能够知道一个帧从那个比特开始到那个比特结束。控制信息还使接收端能够检测到所收到的帧中有没有差错。
⑤ 物理层
物理层的任务就是透明的传送比特流。在物理层上所传输的数据的单位是比特。传递信息所利用的一些物理媒介,如双绞线、同轴电缆、光缆等,并不是在物理层之内而是在物理层的下面。因此也有人把物理媒体当做第0层。
如果想进一步交流和学习的同学,可以加一下QQ群哦!