查漏补缺——网络
计算机网络可谓是计算机专业的必修课了,可见它的重要性了。在面试中也是经常会问到相关的问题,可是这里面内容真的是非常庞杂的。这篇文章,就记录一些自己实际被问过以及一些看到被问过的相关知识点。面试之前,可以拿出来品一品。
计算机网络分层
计算机网络是个非常复杂的系统,所以网络有自己的分层模型。
一种是 ISO(国际标准化组织)制定的 OSI(Open System Interconnect)模型,它将网络分为七层。
一种是 TCP/IP 的四层网络模型。OSI 是一种学术上的国际标准,理想概念,TCP/IP 是事实上的国际标准,被广泛应用于现实生活中。
各层含义
- 应用层
应用层的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间通信和交互的规则。应用层交互的数据单元成为 报文。
如 HTTP 协议。
- 运输层
运输层的任务是负责向两个主机中进程之间的通信提供通用的数据传输服务。应用进程利用该服务传输应用层报文。
这里主要使用一下两种协议:
- 传输控制协议 TCP——提供面向连接、可靠地数据传输服务,其数据传输的单位是 报文段。
- 用户数据报协议 UDP——提供无连接的、尽最大努力的数据传输服务(不保证数据传输的可靠性),其数据传输的单位是 用户数据报。
- 网络层
网络层负责为分组交换网上的不同主机提供用心服务。
- 数据链路层
网络接口层(有时人们也将网络接口层与硬件层合并起来称作网络通信层。) 利用以太网中的数据链路层进行通信,因此属于接口层。
- 物理层
这种硬件就相当于以太网或电话线路等物理层的设备。
主要功能是:利用传输介质为数据链路层提供物理连接,负责处理数据传输并监控数据出错率,以便数据流的透明传输。
TCP
TCP协议的特点
- 面向连接的运输层协议。——在使用 TCP 协议之前,必须先建立 TCP 连接。
- 每一个 TCP 连接只能有两个端点,TCP 连接只能是一对一的。(TCP 连接的端点是个很抽象的套接字,即(IP地址:端口号)例:191.1.1.1:80)
- 提供可靠交付的服务。通过 TCP 连接传送的数据,无差错、不丢失、不重复、并且按序到达。(为什么可靠?)
- TCP 提供全双工通信。两端都设有发送缓存及接收缓存。
- 面向字节流。流指的是流入到进程或从进程流出的字节序列。
TCP 协议的报文结构
控制位
CWR:CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段,ECE 标志为 1 时,则通知对方已将拥塞窗口缩小;
ECE:若其值为 1 则会通知对方,从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1.;
URG:该位设为 1,表示包中有需要紧急处理的数据,对于需要紧急处理的数据,与后面的紧急指针有关;
ACK:该位设为 1,确认应答的字段有效,TCP规定除了最初建立连接时的 SYN 包之外该位必须设为 1;
PSH:该位设为 1,表示需要将收到的数据立刻传给上层应用协议,若设为 0,则先将数据进行缓存;
RST:该位设为 1,表示 TCP 连接出现异常必须强制断开连接;
SYN:用于建立连接,该位设为 1,表示希望建立连接,并在其序列号的字段进行序列号初值设定;
FIN:该位设为 1,表示今后不再有数据发送,希望断开连接。当通信结束希望断开连接时,通信双方的主机之间就可以相互交换 FIN 位置为 1 的 TCP 段。每个主机又对对方的 FIN 包进行确认应答之后可以断开连接。不过,主机收到 FIN 设置为 1 的 TCP 段之后不必马上回复一个 FIN 包,而是可以等到缓冲区中的所有数据都因为已成功发送而被自动删除之后再发 FIN 包;
TCP 三次握手
为什么需要三次握手?
- 要使每一方能够确认对方的存在。
在三次握手过程中,我们可以确认的状态是:
第一次握手:服务器确认自己接收OK,服务端确认客户端发送OK。
第二次握手:客户端确认自己发送OK,客户端确认自己接收OK,客户端确认服务器发送OK,客户端确认服务器接收OK。
第三次握手:服务器确认自己发送OK,服务器确认客户端接收OK。
只有握手三次才能达到全双工的目的:确认自己和对方都能够接收和发送消息。
- 允许双方协商一些参数。(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)
- 能够对运输实体资源进行分配。(如缓存大小,连接表中的项目)
三次握手过程
A 发出请求报文段。
(同步位 SYN=1, 初始序号 seq=x) 客户进入 SYN-SENT 状态。(同步已发送)
B 收到请求报文段后,同意连接则发送确认。
(同步位 SYN=1, 确认号 ACK=x+1, 初始序号 seq=y) 服务器进入 SYN-RCVD 状态(同步收到)
A 收到 B 的确认后,还需要向 B 确认。
(确认号 ACK=y+1, 初始序号 seq=x+1) 客户端进入 ESTABLISHED 状态 ,B 收到确认后也进入 ESTABLISHED 状态。(已建立连接)
TCP四次挥手
为什么需要四次挥手?
当服务器收到 FIN 报文时,很可能并不会立即关闭 SOCKET,所以只能先回复一个 ACK 报文,告诉客户端『你发的 FIN 我收到了』。只有等到服务端所有的报文都发送完了,才能发 FIN 报文,所以要将 ACK 和 FIN 分开发送,这就导致需要四次挥手。
四次挥手过程
A 向其 TCP 发出连接释放报文段,并停止发送数据,主动关闭 TCP 连接。
(终止控制位 FIN=1, 确认位 ACK=1, 序号 seq=u 等于前面已传送过的数据的最后一个字节的序号加 1) 客户进入 FIN-WAIT-1 状态 (终止状态1),等待 B 的确认。
B 收到连接释放报文段后即发出确认。
(确认位 ACK=u+1, 序号 seq=v) 服务器进入 CLOSE-WAIT 状态 (关闭等待)。
此时 TCP 处于半关闭状态,即 A 没有数据发送,但 B 若发送数据,A 仍要接收。也就是说:A 到 B 方向的连接关闭,但是 B 到 A 的连接并未关闭,这个状态可能会持续一段时间。
A 收到 B 的确认后,会进入 FIN-WAIT-2 状态 (终止状态2),等待 B 发出的连接释放报文段。
B 已经没有向 A 发送的数据,向其发送释放报文段。
(终止控制位 FIN=1, 确认位 ACK=u, 序号 seq=w) 服务器进入 LAST-ACK 状态 (最后确认),等待 A 的确认。
A 收到 B 的连接释放报文段后,必须对此发出确认。
(确认位 ACK=w+1, 序号 seq=u) 客户进入 TIME-WAIT 状态 (时间等待)。
此时 TCP 连接还未释放,必须等待 时间等待计时器 设置的 2MSL(MSL:最长报文段寿命,RFC 793 建议为 2 分钟)后,客户才进入 CLOSE 状态。因此 A 进入到 TIME-WAIT 后需要 4 分钟才真正进入到 CLOSE 状态。
最后这个时间,避免 A 最后发送的确认数据未到达 B,在超时之后再次发送确认给 B,重新启动 2MSL 计时器。最后 A 和 B 都正常进入到 CLOSE 状态。
TCP可靠传输是如何实现的?
停止等待协议
A 为发送方, B 为接收方。
分为几种情况
无差错情况。
A 发送数据 M1,B 接收到之后,发送确认收到 M1 消息,A 收到确认后,继续发送 M2。超时重传
A 发送数据 M1,B 接收 M1 之后检测除了差错,丢弃 M1 消息并且什么都不做(也可发送“否认报文”,可以让发送方及早发现并重传,但是会增加协议复杂度,现在都不使用),A 超过一段时间收不到确认消息后,再次发送 M1。
- A 发送完之后,必须暂时保留已发送数据的副本。收到相应数据的确认后才能清楚暂时保留的副本。
- 发送的数据都必须进行编号。
- 超时计时器设置的重传时间应当比数据在传输的平均往返时间更长一些。
确认丢失
A 发送数据 M1,B 接收到之后,发送确认收到消息,但是确认消息丢失,A 在设置的超时时间内没有收到确认,继续发送 M1,B 会收到下一次的 M1,此时 B 应该丢弃这个重复的 M1,并向 A 发送确认收到消息。确认消息迟到
A 发送数据 M1,B 接收到之后,发送确认收到 M1 的消息,A 在设置的超时时间内没有收到确认,继续发送 M1,B 会收到下一次的 M1,此时 B 应该丢弃这个重复的 M1,并向 A 发送确认收到消息,A 在后续传输过程中收到迟到的 M1 确认消息,此时 A 什么都不做。
对比
UDP TCP 是否连接 无连接 面向连接 是否可靠 不可靠传输,不使用流量控制和拥塞控制 可靠传输,使用流量控制和拥塞控制 连接对象个数 支持一对一,一对多,多对一和多对多交互通信 只能是一对一通信 传输方式 面向报文 面向字节流 首部开销 首部开销小,仅8字节 首部最小20字节,最大60字节 适用场景 适用于实时应用(IP电话、视频会议、直播等) 适用于要求可靠传输的应用,例如文件传输
结论
- TCP向上层提供面向连接的可靠服务 ,UDP向上层提供无连接不可靠服务。
- 虽然 UDP 并没有 TCP 传输来的准确,但是也能在很多实时性要求高的地方有所作为
- 对数据准确性要求高,速度可以相对较慢的,可以选用TCP
DNS
DNS,即“Domain Name System”中文通常翻译成“域名系统”。因为32位的 IP 地址难以记忆,为了便于推广,引进了域名这一概念,于是我们才能方便地记下许多难记的域名。于是也就有了 DNS 服务器来对我们输人的域名进行解析,转换成该服务器的IP地址以达到访问的目的。
DNS 解析流程
- 在浏览器中输入 www.qq.com 域名,操作系统会先检查自己本地的 hosts 文件是否有这个网址映射关系,如果有,就先调用这个 IP 地址映射,完成域名解析。
- 如果 hosts 里没有这个域名的映射,则查找本地 DNS 解析器缓存,是否有这个网址映射关系,如果有,直接返回,完成域名解析。
- 如果 hosts 与本地 DNS 解析器缓存都没有相应的网址映射关系,首先会找 TCP/IP 参数中设置的首选 DNS 服务器,在此我们叫它本地 DNS 服务器,此服务器收到查询时,如果要查询的域名,包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析,此解析具有权威性。
- 如果要查询的域名,不由本地 DNS 服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个 IP 地址映射,完成域名解析,此解析不具有权威性。
- 如果本地 DNS 服务器本地区域文件与缓存解析都失效,则根据本地 DNS 服务器的设置(是否设置转发器)进行查询,如果未用转发模式,本地 DNS 就把请求发至根 DNS,根 DNS 服务器收到请求后会判断这个域名(.com)是谁来授权管理,并会返回一个负责该顶级域名服务器的一个 IP。本地 DNS 服务器收到 IP 信息后,将会联系负责 .com 域的这台服务器。这台负责 .com 域的服务器收到请求后,如果自己无法解析,它就会找一个管理 .com 域的下一级 DNS 服务器地址(http ://qq.com)给本地 DNS 服务器。当本地 DNS 服务器收到这个地址后,就会找 http ://qq.com 域服务器,重复上面的动作,进行查询,直至找到www . qq .com主机。
- 如果用的是转发模式,此 DNS 服务器就会把请求转发至上一级 DNS 服务器,由上一级服务器进行解析,上一级服务器如果不能解析,或找根 DNS 或把转请求转至上上级,以此循环。不管是本地 DNS 服务器用是是转发,还是根提示,最后都是把结果返回给本地 DNS 服务器,由此 DNS 服务器再返回给客户机。
HTTP
HTTP 协议
- HTTP 协议构建于 TCP/IP 协议之上,是一个应用层协议,默认端口号是 80
- 灵活:HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。
- 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。
- 无状态:HTTP 协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传。
HTTP 工作流程
- 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
- 解析出 IP 地址后,根据该 IP 地址和默认端口 80,和服务器建立TCP连接;
- 浏览器发出读取文件(URL 中域名后面部分对应的文件)的 HTTP 请求,该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
- 服务器对浏览器请求作出响应,并把对应的 html 文本发送给浏览器;
- 释放 TCP 连接;
- 浏览器将该 html 文本并显示内容;
HTTPS 协议
HTTP 的不足之处:
- 通信使用明文,内容可能会被窃听。
- 不验证通信方的身份,因此有可能遭遇伪装。
- 无法证明报文的完整性,所以有可能遭到篡改。
于是就引出了 HTTPS 协议。
HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议,SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。
- 对称加密
对称加密指的就是加密和解密使用同一个秘钥,所以叫做对称加密。对称加密只有一个秘钥,作为私钥。
常见的对称加密算法:DES,AES,3DES等等。
- 非对称加密
非对称加密指的是:加密和解密使用不同的秘钥,一把作为公开的公钥,另一把作为私钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。
常见的非对称加密算法:RSA,ECC
HTTPS 工作流程
SSL
安全套接字(Secure Socket Layer,SSL)协议是 Web 浏览器与 Web 服务器之间安全交换信息的协议。
SSL协议的三个特性
保密:在握手协议中定义了会话密钥后,所有的消息都被加密。
鉴别:可选的客户端认证,和强制的服务器端认证。
完整性:传送的消息包括消息完整性检查(使用MAC)。
工作流程
客户端请求建立 SSL 连接,并将自己支持的一套加密规则发送给网站。
网站从中选出一组加密算法与 HASH 算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息
获得网站证书之后浏览器要做以下工作:
验证证书的合法性
如果证书受信任,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。
使用约定好的 HASH 计算握手消息,
使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。
网站接收浏览器发来的数据之后要做以下的操作:
使用自己的私钥将信息解密取出密码
使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。
使用密码加密一段握手消息,发送给浏览器
浏览器解密并计算握手消息的 HASH,如果与服务端发来的 HASH 一致,此时握手结束。
使用随机密码和对称加密算法对传输的数据加密,传输。
HTTPS 协议与 HTTP 协议的区别
HTTPS 协议需要到 CA 申请证书,一般免费证书较少,因而需要一定费用。
HTTP 是超文本传输协议,信息是明文传输,HTTPS 则是具有安全性的 SSL/TLS 加密传输协议。
HTTP 和 HTTPS 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443。
HTTP 的连接很简单,是无状态的;HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全。