计算机网络知识总结
OSI开放式互联网参考模型
1. 物理层
定义物理设备标准,如网线类型,光纤接口类型,传输速率等,主要作用为传输比特流^①^
① 比特流即0 1数据,将其转化为电流的强弱进行传输
数据:比特
网卡
工作在本层
2. 数据链路层
定义了如何格式化数据以进行传输,以及如何控制对物理介质的访问,通常提供错误检测和纠正,以确保数据传输的可靠性
数据:帧
交换机
工作在本层
3. 网络层
主要功能是将网络地址翻译为对应的物理地址,并决定如何将数据从发送方路由至接收方
数据:数据包
协议:IP,RIP等
路由器
工作在本层
4. 传输层
解决主机之间的数据传输,并且解决了传输质量的问题,是OSI模型中最重要的一层
协议:TCP,UDP等
5. 会话层
建立和管理应用程序之间的通信
6. 表示层
解决不同系统间通信的语法问题
7. 应用层
规定发送方和接收方必须使用同一个固定长度的消息头,消息头必须使用某种固定组成,消息头中必须记录消息体的长度等信息,方便接收方正确解析发送方发送的数据
协议:HTTP,FTP等
TCP/IP
OSI七层模型只是一种概念模型,并没有提出实现的方式,TCP/IP在一定程度上实现了OSI,虽然并不完全满足OSI,但也被认为是OSI的一种实现
OSI七层模型 | TCP/IP模型 | 功能 | TCP/IP协议族 |
---|---|---|---|
应用层 | 应用层 | 文件传输,电子邮件,文件服务 | HTTP、FTP、TFTP、Telnet |
表示层 | 数据格式化,数据加密 | 无 | |
会话层 | 解除,建立与其他站点之间的联系 | 无 | |
传输层 | 传输层 | 提供端对端接口 | TCP、UDP |
网络层 | 网络层 | 为数据包选择路由 | IP、RIP、ICMP、OSPF |
数据链路层 | 链路层 | 传输有地址的帧及错误检测 | SLIP、PPP、CSLIP |
物理层 | 以二进制在物理媒介上传输数据 | ISO2110 |
TCP/IP不单只TCP
和IP
这两个协议,它泛指IP
、TCP
、UDP
、HTTP
等协议
TCP
Transmission Control Protocol 传输控制协议
① TCP是面向连接的,可靠的,基于字符流的传输层通信协议
② 每一条TCP连接只能有两个端点,每个TCP连接只能是点对点的^①^
③ TCP提供全双工通信^②^
① 点对点即一对一通信
② 全双工通信即通信的双方可以同时进行双向传输数据
TCP将应用层的数据流分割成报文段并发送给目标节点的TCP层;TCP发送的每个数据包都有序号,对方收到数据则发送ACK确认,未收到则会进行重传;TCP使用校验和来检测数据在传输过程中是否有误
TCP的三次握手
① 发送方主动打开服务器,接收方被动打开服务器,发送方向接收方发出连接请求报文,报文中的同步序号SYN = J
,然后发送方进入SYN-SENT同步已发送状态,发送的报文段称为请求报文
,不携带数据
② 接收方收到请求报文后,若同意连接,则向发送方发出确认报文,报文中包含ACK = J + 1
,SYN = K
,之后接收方进入SYN-REVD同步收到状态,确认报文同样不携带数据
③ 发送方收到确认后,再向接收方发送一个确认ACK = K + 1
,此时,TCP连接建立,该报文的ACK报文段可以携带数据,也可以不携带数据
为什么TCP需要三次握手
第一次:发送方向接收方发送请求报文,接收方收到,则接收方确认发送方发送正常,接收方接收正常
第二次:接收方向发送方发送确认报文,发送方确认自己发送和接收正常,对方发送接收正常
第三次:发送方向接收方发送确认报文,双方都能确认自己和对方的接收发送都正常
发送方确认状态 | 接收方确认状态 | |||||||
---|---|---|---|---|---|---|---|---|
自己发送正常 | 自己接收正常 | 对方发送正常 | 对方接收正常 | 自己发送正常 | 自己接收正常 | 对方发送正常 | 对方接收正常 | |
第一次 | × | × | × | × | × | √ | √ | × |
第二次 | √ | √ | √ | √ | × | √ | √ | × |
第三次 | √ | √ | √ | √ | √ | √ | √ | √ |
首次握手的隐患-SYN超时
当接收方收到发送方的SYN
,回复SYN-ACK
时发送方掉线,接收方无法收到ACK确认,该链接则会处于一个中间状态,即不成功也不释放,该状态下发送方会不断重发直至超时(Linux下默认重发5次,等待63秒后断开连接)
在此期间可能使服务器受到SYN-blood
攻击,恶意程序会向服务器发送SYN
,发送后立刻下线,因此服务器在63秒后才会断开连接,恶意程序会将服务器的SYN队列耗尽,使得正常的请求无法被处理
SYN blood的防护措施
当SYN队列满后,通过tcp_syncookies
参数回发SYN Cookie
,若为正常连接,客户端会回发SYN Cookie
,直接建立连接
保活机制
建立连接后,客户端出现故障,开启保活功能的一端向另一端发送保活探测报文,若未收到响应,会在保活时间内继续发送,若尝试次数达到保活探测数但仍未收到响应则断开连接
TCP报文中的控制位
控制位由8个标志位组成,每个标志位表示一个控制功能
ACK确认序号标志:为1表示确认号有效,为0表示忽略确认号字段
SYN同步序号:用于建立连接
FIN终止标志:用于释放连接,为1时表示发送方没有发送了
seq序号
占TCP报文4字节,TCP连接中传送的字节流中的每个字节都按顺序编号
ack确认号
占TCP报文4字节,是期望收到对方下一个报文段的第一个数据字节的序号
TCP四次挥手
① 主动终止方发送连接释放报文FIN = 1
,并停止发送数据,进入FIN-WAIT-1终止等待1状态
② 被动终止方收到释放报文后,发出一个确认报文ACK = 1
,并进入CLOSE-WAIT关闭等待状态
③ 被动终止方发送完最后的数据后,向主动终止方发送连接释放报文FIN = 1 ACK = 1
,被动终止方进入LAST-ACK最后确认状态
④ 主动终止方收到释放报文后,再发送一个确认报文ACK = 1
,并进入TIME-WAIT时间等待状态,等待2MSL后关闭连接;被动终止方收到确认ACK后,立即进入关闭状态
为什么会有TIME-WAIT状态(为什么主动终止方需要等待一段时间关闭)
确保有足够的时间让对方接收到ACK报文,若被动端没有接收到ACK,则会重发FIN-ACK
,MSL为报文最大存活时间,2MSL及主动方ACK
发送的时间+被动方重发FIN-ACK
的时间,2MSL可以确保网络中没有报文存活
为什么需要四次挥手
由于TCP是全双工通信,即双向通信,双方都有向对方的通信,且双方都需要发送并接受一个FIN和ACK
前两次挥手:主动方关闭向被动方的通信
后两次挥手:被动方关闭向主动方的通信
服务器出现大量CLOSE-WAIT的原因
对方关闭socket连接,我方忙于读或写,没有及时关闭连接
需要检查释放资源的代码和请求的线程配置
UDP
User Datagram Protocol 用户数据报协议
① UDP是面向非链接的
传输数据之前,源端与终端不建立连接,当它希望传送数据时,就简单抓取来自应用程序的数据,并尽可能快的将它扔到网络上
在发送端,UDP传输数据的速度仅受应用程序生成数据的速度,计算机能力和传输带宽的限制
在接收端,UDP把每个报文段放入队列中,应用程序每次从队列中读取一个报文段
② UDP提供尽最大努力交付,不保证可靠交付,主机无需维持复杂的连接状态
③ UDP是面向报文的,不对应用程序提交的报文信息进行合并或拆分
④ UDP没有拥塞控制,网络拥塞时不会降低源端速率
⑤ UDP支持一对一,一对多,多对一,多对多的交互通信
⑥ UDP首部开销小,及8字节
TCP和UDP的区别
① TCP是面向连接的;UDP面向无连接
② TCP可靠,利用握手和重传机制提供可靠性;UDP不可靠,可能丢失数据
③ TCP利用序列号保证消息的顺序交付,到达可能无序但最终排序;UDP无序
④ TCP速度慢^①^;UDP速度快,适合对速度敏感的应用
⑤ TCP属于中量级协议,首部20字节;UDP属于轻量级协议,首部8字节
① TCP速度慢是因为其创建链接,保证可靠性和有序需要消耗时间
是否面向连接 | 可靠性 | 传输形式 | 传输效率 | 所需资源 | 首部字节 | |
---|---|---|---|---|---|---|
TCP | 面向连接 | 可靠 | 字节流 | 慢 | 多 | 20字节 |
UDP | 面向无连接 | 不可靠 | 报文段 | 快 | 少 | 8字节 |
TCP滑动窗口
TCP将数据分成段来发送,出于对效率和传输速率的考虑,不可能一段一段的发送数据,等上一段数据确认后再发送下一段数据
要实现对数据的批量发送,TCP要解决可靠性和包乱序的问题,因此TCP需要知道网络实际的数据处理带宽和数据处理速度,这样才不会引起网络拥塞而导致丢包
RTT
Round Trip Time 往返时延:发送一个数据包到收到对应的ACK所花费的时间
RTO
Retransmission TimeOut 重传超时值:重传时间间隔。TCP在发送一个数据包后会启动一个重传定时器,RTO即定时器重传时间
滑动窗口的作用
- 保证TCP的可靠性
- 保证TCP的流量控制特性
TCP报文头部中的
window
字段用于接收方通知发送方自己还有多少缓存区可以接收数据,发送方根据接收方的处理能力来发送数据,不会让接收方处理不过来,这边是流量控制
窗口数据的计算过程
发送端
在发送端缓冲区中
LastByteAcked
指向收到的连续最大的ACK位置,即从左端算起连续被接收方发送ACK确认已收到的seq num
LastByteSent
指向已发送的最后一个字节的位置,该位置已发送但还未收到ACK回应
LastByteWritten
指向上层应用已写完的最后一个字节的位置,即当前程序已经准备好发送的新数据段
LastByteAckes - LastByteSent
之间表示已发送但未收到ACK确认的数据
LastByteAckes
之前是已经发出且受到确认的数据
接收端
在接收端缓冲区中
LastByteRead
指向上层应用已经读取完毕的最后一个字节的位置,即受到发送方数据,已经处理完毕且发送确认回复的最后一个位置
NextByteExpected
指向收到的连续最大的seq的位置
LastByteRcvd
指向已收到的最后一个字节的位置
LastByteRead - NextByteExpected
之间表示已经收到但还未发送回执的数据
NextByteExpected - LastByteRcvd
之前有些seq还未到达,对应空白区域
根据以上数值可以计算出接收方AdvertisedWindow
的大小,并将其回发给发送方,让其计算出发送方剩余可发送的数据大小,即EffectiveWindow
的大小
接收方还能接受的数据大小
$$AdvertisedWindow = MaxRecBuffer - (LastByteRcvd - LastByteRead)$$
MaxRecBuffer
表示接收方缓存区中的最大缓存
(LastByteRcvd - LastByteRead)
表示当前接收方已经接收到的数据会还未接收到的预定数据留出的空间,这些空间已经占据一些缓存
用接收方的最大缓存减去已经占用的缓存得到接收方还可以接收的数据量,进而将AdvertisedWindow
告知发送端
发送方还能发送的数据大小
发送方需要根据ACK中的AdvertisedWindow
值,来保证LastByteSend - LastByteAcked <= AdvertisedWindow
,即已发送待确认的数据量小于接收方的window大小
窗口内剩余可发送的数据量
$$EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked)$$
(LastByteSent - LastByteAcked)
表示已发送待确认的数据,以接收方的AdvertisedWindow
为基准,减去发送方发出待确认的数据,剩下的空间就是发送方还可以发送的数据
滑动窗口的基本原理
TCP会话发送方
在发送方缓存内的数据可以分成四类:
- 已经发送并得到回应的
- 已经发送但未得到回应的
- 未发送但对端允许发送的
- 未发送且由于打到window的大小,对端不允许发送的
2和3共同组成发送方的发送窗口
当收到接收方新的ACK对发送窗口中后续字节的确认时,窗口就会滑动,滑动原理如下
假设原滑动窗口的边界是6到16,假设已发送但未被确认的序号是6到12,若6和7未被确认,但8被确认了,这时窗口不会向右滑动,只有6和7也被确认,即6到8被连续确认之后,窗口才会向右滑动
在窗口未滑动之前,序号大于等于17的数据,即滑动窗口外的数据都不能被发送,若6到8都被确认,窗口会向右滑动3位,即从6到16滑动到9到19,进而程序可以发送17到19的数据
TCP会话接收方
在接收方的接收缓存内的数据可分为三类:
- 已接受且已发送回执的
- 未接收但可以接收的
- 未接收且不能接收的
2即为发送方的接收窗口
由于ACK直接由TCP栈回复,默认没有应用延时,所以不存在已接受但未发送回执的数据
TCP传输的可靠性来自确认重传机制,TCP滑动窗口的可靠性也是基于确认重传机制,发送端只有接收到接收端对于本段发送窗口内字节的ACK确认,才会移动发送窗口的左边界
接收窗口只有在前面所有的段都确认的情况下才会移动左边界,当前面还有字节未被接收但收到后续字节的情况下,窗口不会移动,不对后续字节进行确认,以确保对端能够对这些数据回传
滑动窗口的大小可以根据一定策略动态调整,应用会根据自身的处理能力的变化,通过对本端接收窗口的控制来进行对对端发送窗口的流量控制
HTTP
Hypertext Transfer Protocol 超文本传输协议,是基于请求响应模型的无状态的应用层协议,绝大多数的web开发是构建在HTTP协议上的web应用
① 支持客户/服务器模式
浏览器作为HTTP客户端通过URL向服务器端,即web服务器发送请求,web根据接收到的请求向客户端发送响应消息
② 简单快捷
客户端向服务器请求服务时只需要传送请求方法和请求路径,常用请求方法有get,post,每种方法规定了客户与服务器联系的类型不同,由于HTTP协议简单,HTTP服务器程序规模小,所以通信快
③ 灵活
HTTP允许传输任意形式的数据对象,正在传输的数据由
Content-type
加以标记
④ 无连接
限制每次连接只处理一个请求,服务器收到客户请求,并收到客户响应后,即断开连接
从HTTP1.1起默认使用长连接,即服务器需要等待一段时间后才断开连接,以保证连接特性
在每个独立的HTTP请求中,无法得知当前的HTTP是否处于长连接的状态,始终认为HTTP在请求结束后会关闭连接,这是HTTP的特性,下层实现是否在请求结束后关闭连接都不会改变这个特性
⑤ 无状态
协议对于事务处理没有记忆能力,缺少状态就意味着如果后续请求需要之前的信息,就必须重传之前的信息,这样可能导致每次连接传送的数据量增大;另一方面,若服务器不需要之前的信息,它的应答就比较快
HTTP1.0和1.1的区别
① 长连接
HTTP1.1默认开启长连接,在一个TCP连接上可传送多个HTTP请求和响应
HTTP1.0需要使用
keep-alive
来告知服务器建立一个长连接
② 节约带宽
HTTP1.0中存在一些浪费带宽的现象,如客户端只需要某个对象的一部分,但是服务器将整个对象传递过来,且不支持断点续传
HTTP1.1支持只发送header信息
③ HOST域
HTTP1.0中认为每台服务器都绑定一个唯一的IP,因此,请求消息中的URL并没有传递主机名,1.0中没有host域
如今一台物理服务器上可以存在多个虚拟主机,且它们共享同一个IP,HTTP1.1中的请求和响应消息都支持host域,且请求消息中若没有host域会报告400 Bad Request
④ 缓存策略
HTTP1.0主要使用header中的
if-Modified-Since
,Expries
来作为缓存判断标准HTTP1.1中引入了更多的控制策略
⑤ 错误通知管理
HTTP1.1新增了24个错误响应状态码
HTTP1.1和HTTP2.0的区别
多路复用,头部压缩,服务器推送
HTTP请求结构
① 请求行:由请求方法(GET,POST),请求URL和协议版本组成
② 请求头:由若干报文段组成,每个报头都是头部字段名:值,名字大小写无关。报头用来设置HTTP请求参数
③ 请求空行:用于分隔请求头和请求体,且没有请求体的情况下依旧存在该空行
④ 请求体:只在POST请求中使用,表示需要上传的数据
HTTP响应结构
① 状态行:由协议版本,状态码,状态码描述组成
② 响应头:组成与请求头相同,用于说明客户端的附加信息
③ 响应空行:用于分隔响应头和响应体
④ 响应体:即响应正文
请求响应步骤
① 客户端连接到web服务器
HTTP客户端通常是浏览器,与web服务器的HTTP端口(默认为80端口)建立TCP套接字连接
② 客户端发送HTTP请求
客户端通过TCP套接字向web服务器发送文本请求报文
③ 服务器收到请求并返回HTTP响应
④ 释放TCP连接
若连接模式为close,则服务器主动关闭TCP连接
若连接模式为keep-alive,则该连接会保持一段时间,期间可以继续接收请求
⑤ 客户端解析HTML内容
客户端浏览器首先解析状态行,查看成功状态码,之后解析每个响应头,再读取响应HTML将其格式化,并显示到浏览器窗口
常见的HTTP状态码
1XX
指示信息,表示请求已接受,继续处理
2XX
成功,表示请求被成功接收
200 OK:成功并正常返回消息
3XX
重定向,要完成请求需要进一步操作
301 永久性转移:旧地址资源被永久删除
302 暂时性转移:旧地址资源还在,只是临时跳转到新地址
4XX
客户端错误,请求由语法错误或请求无法实现
400 Bad Request:客户端有语法错误,服务器无法理解
401 Unauthorized:缺失或错误的认证
403 Forbidden:客户端请求没有权限访问要求的资源
404 Not Found:请求资源不存在
5XX
服务器错误
500 Internal Server Error:服务器发生不可预测的错误
502 Bad GateWay:服务器作为网关或代理时,未完成请求访问下一个服务器,但该服务器返回了非法应答
503 Server Unavailable:服务当前不能处理客户端请求,一段时间后可能恢复
504 GatewayTimeOut:网关超时,由作为代理或网关的服务器使用,表示无法及时从远程服务器得到应答
GET请求和POST请求的区别
① 报文层面
GET请求将信息拼接在URL之后,请求消息与URL之间用?
隔开,其请求长度有限制
POST请求消息存放在请求体中,请求消息没有长度限制
② 数据库层面
GET符合幂等性和安全性,GET是查询操作,不会改变数据库内容,大致认为符合安全性和幂等性
POST不符合安全性和幂等性,POST请求会提交数据,改变数据库内容
幂等性:对数据库的一次和多次操作得到的结果一致
安全性:对数据库的操作不会改变数据库的数据
③ 其他层面
GET可以被缓存,其URL可以当做书签保存
POST不能被缓存
Cookie和Session的区别
Cookie基于响应头Set-cookie
和请求头cookie
实现,当客户端第一次请求服务器,服务器会将cookie中的数据设置到响应头中的Set-cookie
中,在之后的请求中,客户端将cookie内容存放在请求头的cookie
中发送给服务器
Session基于Cookie实现,服务器给Session分配一个唯一的JSESSIONID
,并通过cookie发送给客户端,客户端重新发送请求时,会在cookie中携带该id,服务器通过这个id找到对应的Session
区别①:Cookie存放在客户端,Session存放在服务器
区别②:Session相对安全,且没有大小限制
HTTPS
Hyper Text Transfer Protocol over SecureSocket Layer 超文本传输安全协议,是在HTTP的基础上添加了SSL层,从而保证了交换数据的隐私,具有完整性和对网上服务器身份验证的功能
SSL
SecureSocket Layer 安全套接层,为网络通信提供安全及数据完整性的安全协议,位于TCP和各应用层之间,采用身份验证和数据加密来保证网络通信的安全性和数据完整性
在SSL3.0之后更名为TLS
加密方式
- 对称加密:加密解密使用同一个密钥(DES,AES,RC2,RC4)
- 非对称加密:加密使用公钥,其算法公开;解密使用私钥,非对称加密的性能低,安全性高,能加密的数据长度有限(RSA,ECC)
- 哈希算法:将任意长度的信息转换为固定长度的值,其算法不可逆(MD5)
- 数字签名:证明某个信息是由某人发出、认同的
HTTPS采用证书配合多种加密手段
HTTPS传输流程
- 浏览器将支持的加密算法信息发送给服务器
- 服务器选择浏览器支持的加密算法,以证书的方式回发给浏览器
- 浏览器验证证书的合法性,并结合证书公钥加密信息发送给服务器
- 服务器使用私钥解密信息,验证哈希,加密响应消息,回发给浏览器
- 浏览器解密响应消息,并对消息进行验真,之后双方加密交换数据
HTTP和HTTPS的区别
① HTTPS需要CA证书,HTTP不需要
② HTTPS密文传输,HTTP明文传输
③ HTTPS默认443端口,HTTP默认80端口
④ HTTPS中的SSL有状态,HTTP无状态
HTTPS = HTTP + 证书 + 加密 + 完整性保护
评论