这里跟大家分享下我复习时整理的计算机网络常考知识点。
网络协议
OSI7层模型
- 物理层:传输物理比特
- 数据链路层:将比特封装成帧
- 网络层:将网络地址翻译成物理地址,路由选择。路由器。分组:数据报。IP协议
- 传输层:将大数据分割传给网络层,流量控制。TCP,UDP协议
- 会话层:建立应用程序的通讯
- 表示层:解决不同系统间通信语法问题
- 应用层:通过应用进程间的交互来完成特定网络应用,报文
TCP/IP4层模型(相比5层少一个物理层)
-
物理层:物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。
-
链路层:两台主机之间的数据传输,总是在一段一段的链路上传送的,这就需要使用专门的链路层的协议。数据报组装成帧。
-
网络层:网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。数据报, IP
-
传输层:负责向两台主机进程之间的通信提供通用的数据传输服务,TCP/UDP
-
应用层:通过应用进程间的交互来完成特定网络应用,报文,HTTP,DNS,SMTP
三次握手
- tcp报文头:
- Sqquence Number:4字节,报文序号,若当前107带了100字节,则下一次序号207。
- Acknowledgment Number:4字节,期望收到下一个报文的下一个字节序好,B发送了201序号300字节的数据,期望收到A501的ack,故B的确认号写501。
- TCP Flages;
- URG:
- ACK:确认标识
- PSH:
- RST:重置连接标志
- SYN:同步序号,用于建立连接过程
- FIN:finish标识
+
- 为什么要三次握手才能建立连接:初始化Sequence Number的初始值
- SYN超时:Server收到Client的SYN,回复SYN-ACK时未收到ACK确认,Server不断重试,linux默认等63秒,可能会照成占用服务器资源。可使用SYN-cookie解决。
- 建立连接后,Client故障:保活机制,发送饱和报文,直至到达饱和次数
四次挥手
- 为什么要有TIME_WAIT
- 1、保证对方收到ACK包
- 2、避免新旧连接混淆
- 为什么需要四次挥手 :全双工,发送方与接收方都与要发送FIN与ACK
- 服务器出现大量CLOSE_WAIT:对方关闭socket连接,我方忙于读或写,没有及时关闭
- 检查代码,特别是资源释放的
- 检查配置,特别是处理请求的线程配置,如:线程池中的线程数字
为什么建立连接协议是三次握手,而关闭连接却是四次握手?
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你未必会马上会关闭SOCKET,即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
UDP简介
- 特点:1、面向非连接 2、不维护连接状态 3、抱头8字节很小 4、吞吐量只受数据生成,传输速率限制 5、不提供拆分报文
- TCP与UDP区别:
- 面向连接与无连接
- 可靠性
- 有序性
- 速度
- 量级
TCP 协议如何保证可靠传输
- 应用数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
- 校验和: TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。TCP 的接收端会丢弃重复的数据。
- 流量控制: TCP 连接的每一方都有固定大小的缓冲空间,TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 (TCP 利用滑动窗口实现流量控制)
- 拥塞控制: 当网络拥塞时,减少数据的发送。慢开始 、 拥塞避免 、快重传 和 快恢复。
- ARQ协议: 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
- 超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段
TCP的滑动窗口
- RTT和RTO
- RTT:发送数据包到收到ACK所花费的时间
- RTO:重传时间间隔
- 作用:提供可靠性与流控制性
拥塞控制
拥塞窗口:
发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞。
慢开始算法:
当主机开始发送数据时,如果立即所大量数据字节注入到网络,那么就有可能引起网络拥塞,因为现在并不清楚网络的负荷情况。因此,较好的方法是 先探测一下,即由小到大逐渐增大发送窗口,也就是说,由小到大逐渐增大拥塞窗口数值。
拥塞避免:
让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。
快重传算法:
快重传算法首先要求接收方每收到一个失序的报文段就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方),然后若是发送方接收到3个重复确认ACK,则启动快重传算法。
快速恢复算法:
与快重传配合使用的还有快恢复算法,其过程有以下两个要点:
- 当发送方连续收到三个重复确认,就执行“乘法减小”算法,把慢开始门限ssthresh减半。
- 与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口cwnd现在不设置为1),而是把cwnd值设置为 慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。
HTTP简介
- 特点:支持C/S模式、简单快速、灵活、短连接(1.1之前,一次处理一个请求,请求结束后关闭)长连接(1.1之后,打开网页后并不会立刻断,下一次访问还用这个)、无状态(协议对于事物处理没有记忆)、请求响应模型
- 请求:请求方法,url,协议版本,请求头部,请求数据
- 相应:协议版本,成功/错误代码,服务器信息,响应头部,响应数据
- 请求响应步骤:客户端连接到WEB服务器,发送HTTP请求、接受请求并返回HTTP相应、释放TCP连接,客户端解析HTML程序
- 键入URL,按下回车后经历的流程
- DNS解析、TCP连接、发送HTTP请求、处理请求并返回报文、浏览器渲染界面、连接结束
- TCP,IP,OPSF(IP数据包在路由器中传输),ARP(IP转MAC),HTTP
- HTTP状态码:
- 1xx:指示信息–请求已接受,继续处理
- 2xx:成功 --表示请求已被成功接收、理解、接受
- 3xx:重定向–要完成请求必须进行更进一步的操作
- 4xx:客户端错误–请求语法错误或请求无法实现
- 5xx:服务器错误–服务器未能实现合法的请求
- 常见状态码:
- GET和POST请求的区别
- HTTP报文层面:GET将请求信息放在URL中,POST放在报文体中
- 数据库层面:GET符合幂等性(一次多次操作一致)和安全性,POST不符合
- 其他层面:GET可以被缓存,被储存,而POST不行
- Cookie和Session区别:
- Cookie:
- 服务器向客户端发送的特殊信息,以文本的形式存放在客户端
- 客户端再次请求时会把Cookie回发,服务器接收后,解析Cookie生成与客户端相对应的内容。