OSI、TCP/IP模型及协议

独立寒秋-

已于 2022-09-24 11:28:58 修改

阅读量1.1k

点赞数

分类专栏：笔记文章标签：网络网络协议 tcp/ip

于 2022-09-16 00:45:26 首次发布

本文链接：https://blog.csdn.net/weixin_51445423/article/details/126882279

版权

笔记专栏收录该内容

28 篇文章 2 订阅

订阅专栏

文章目录

OSI模型：

OSI参考模型，是将ISO（国际标准化组织）提议的模型与CCITT（国际电话电报咨询委员会）提议的标准相互融合的模型。OSI参考模型明确区分了服务、接口和协议三者的概念。

协议：网络协议，是为了确保各方能够相互交流，而给信息的表达、传递等方式所定义的标准或准则。

服务：模型中每一层在作用上的界定，就是定义了每一层应该提供的服务

接口：定义了模型上下层之间互相访问的标准，按照OSI模型的定义方式，每一层通过接口为上层提供服务，同时也接受下一层提供的服务，同一层的设备之间的通信则通过协议来定义标准。

应用层：提供用户接口，包含各类用户常用的协议：
表示层：主要负责信息的加密解密、压缩解压缩、编码方式转换等服务；
会话层：主要负责确认通信方的身份、权限验证等；（）
传输层：规范数据传输的功能和流程和流程，例如对数据分片重组等（数据段）
网络层：将数据从源转发给目的设备。（数据包）
数据链路层：为相连设备或者处于同一个局域网中的设备实现数据帧传输，对数据帧进行校验/控制
物理层:实现信号在两台相邻网络实体之间的传输。（交换单元为比特）

因为把服务划分的过于繁琐，OIS模型没有得到广泛应用。

TCP/IP模型与OSI参考模型的根本区别在于建立标准的方式不同。OIS模型是在对各层对应的协议缺乏充分了解情况下定义服务的，在使用现有的协议和OSI模型来构建网络，往往会出现搭建网络无法满足服务规范的情况。而TCP/IP模型一开始就是对TCP/IP两个协议所作的描述，所以TCP/IP模型定义的服务与TCP/IP协议感度吻合。

TCP/IP模型没有明确划分协议、服务和接口的概念，IP协议起初就是TCP协议中的一个组件，后来才从TCP协议中分离出来。就是说这两个协议完全不需要借助定义接口就可以相互访问。

TCP/IP模型：

应用层：功能与OSI模型的应用层、表示层、会话层之和。常见协议：HTTP、FTP、SMTP、Telenet
传输层：TCP/UDP两个协议
互联网层：让数据实现从源地址到目的地址的转却转发，IP协议
网络接入层：可以看作主机与线路之间的接口

TCP协议

传输控制协议，负责为不同终端系统的应用进程之间提供面向连接的通信服务。它能够对自己提供的连接进行控制，是一种可靠的传输层协议。
因为TCP协议是面向连接的服务，也就是说，在为应用进程之间建立通信之前，TCP需要首先建立传输数据所需的连接。此外TCP协议能够对它所建立的连接进行控制，包括：

对数据执行分割和重组（tcp能够将数据分割分割为适当大小进行传输，发送端分割/结束端重组）
确保数据按顺序传输（发送端会为发送的数据标明一个序列号，接收端根据序列号进行重新排序还原出最初的数据）
同时为多个应用程序提供传输服务（tcp基本任务就是将终端系统中多个应用协议的数据转交给网络层进行发送，这是通过端口号实现的，就是应用进程与数据的对应关系）
确保接受方收到数据并按需传输，tcp要求接收方在接受到数据后，会向发送方进行确认。如果发送方在一段时间后没有接收到接收方的确认，他还会把未确认过的数据重新发一遍（相当于周期性重传）。
控制传输速率 TCP使用滑动窗口的机制，使接收方能够调节发送方的发送速率

TCP报文

TCP报文由首部字段和一个数据字段组成

首部字段

在这里插入图片描述

TCP首部字段一般是20字节（比UDP少12字节）；源端口号和目的端口号被用于多路复用/分解来自或送到上层应用的数据；序号和确认号都是32比特。

序列号32比特，在初次建立连接的时候，客户端和服务端都会为「本次的连接」随机初始化一个序列号。（序列号可以用来解决网络包乱序的问题）
确认号32比特，表示「接收端」告诉「发送端」对上一个数据包已经成功接收
SYN为1时，表示希望创建连接。
ACK为1时，确认号字段有效。（该报文段包括一个对已被成功接收报文段的确认）
FIN为1时，表示希望断开连接
RST为1时，表示TCP连接出现异常，需要断开
接收窗口字段16比特
首部长度字段4比特
选项字段通常为空
6比特的标志字段
RST、SYN、FIN用于连接建立和拆除
CWR、ECE是在拥塞报告中使用的
PSH指示接收方立即将数据交给上层
URG指示报文段里存在“紧急”数据

数据字段

三次握手

在这里插入图片描述

TCP作为一个可靠的传输协议，在传输数据之前，需要在两个终端（两个应用进程）之间建立一条TCP连接。建立连接的过程要经历三次握手，就是两台终端设备之间交换信息的过程：

这个TCP连接是一条逻辑连接，通信双方的共同状态仅保留在两个通信系统的TCP程序中。TCP连接提供的是全双工服务，

客户端向服务器发起TCP连接建立的请求，在发出的数据段中，控制字段中的SYN位会被置为1，表示这是一个连接建立的请求。序列号为随机数a,确认号为0.
服务器在接收到客户端的请求后会向客户端返回标识了SYN和ACK的数据段。控制字段中的SYN和ACK都被置为1。序列号为随机数b,确认号为a+1（确认收到客户端发来的序列号为a的数据段）
客户端向服务器发送ACK数据段进行响应。在发出的数据段中，控制字段的ACK位被置为1，序列号为a+1,确认号为b+1.

完成三次握手后，客户端与服务器之间的TCP连接就建立起来了，他们之间可以通过通过这条链接来传输数据了。TCP协议会确保：接收方确实接收到了发送方发送的数据。发送方按照接收方处理能力发送数据，避免不必要的丢包重传。

三次握手时c/s的状态

在最开始的时候，客户端和服务端都处于 CLOSE 状态
服务器主动监听某个端口，处于 LISTEN 状态
第一次握手：客户端会随机生成出序列号（这里的序列号假设为a），并且把标志位设置为SYN（意味着要连接），然后把该报文发送给服务端。客户端发送完SYN报文以后，自己便进入了 SYN_SEND 状态。
第二次握手：服务端接收到了客户端的请求之后，自己也初始化对应的序列号（序列号假设为b）; 然后服务端在「确认号」字段里填上a+ 1（a是客户端发过来的系列号，相当于告诉客户端，已经收到了发送过来的序列号了），并且把 SYN 和 ACK 标记位置为1。把该报文发送客户端，服务端的状态变成 SYN-REVD 状态
第三次握手：客户端收到服务端发送的报文后，就知道服务端已经接收到了自己的序列号（通过确认号就可以知道），并且接收到了服务端的序列号(b) , 此时，客户端需要告诉服务端自己已经接收到了他发送过来的序列号，所以在「确认号」字段上填上b+1，并且标记位 ACK 为1 。客户端在发送报文之后，进入 ESTABLISHED 状态，而服务端接收到客户端的报文之后，也进入 ESTABLISHED 状态

三次握手的目的：就是双方都把自身的序列号发给对方，看对方能不能接收到。如果「确认可以」，那就可以正常通信。（三次握手这个过程就可以看到双方都有接收和发送的能力）。两次握手只能保证客户端的序列号成功被服务端接收，而服务端是无法确认自己的序列号是否被客户端成功接收。

序列号为什么是随机的 ：为了安全性（随机seq能避免非同一网络的攻击），另一方面可以让通信双方能够根据序号将「不属于」本连接的报文段丢弃。

中途丢包怎么办：假设客户端发送给服务端的 SYN 包丢了（就是服务端没接收到客户端的SYN包）客户端迟迟收不到服务端的ACK包，那会周期性超时重传，直到收到服务端的ACK 。

四次挥手

在这里插入图片描述

TCP建立的是双向链接，当客户端与服务器之间数据传输完毕后，TCP协议通过四次挥手拆除已建立的连接：

在建立完连接之后，客户端和服务端双方都处于 ESTABLISHED 状态状态

第一次挥手：客户端想要中断TCP连接，向服务器发送带有FIN和ACK标识的数据段，序列号为随机数a；客户端发送完之后，就进入FIN_WAIT_1状态。
第二次挥手：服务端收到 FIN 报文之后，以序列号b确认号a+1的数据段进行响应，回复 ACK 报文给客户端（表示已经收到了），服务端发送完之后，就进入 CLOSE_WAIT 状态。然后客户端接收到服务端的 ACK 报文，就进入了 FIN_WAIT_2 状态。
第三挥手：是因为这时候，服务器可能还有数据要发送给客户端，等服务端确认自己已经没有数据返回给客户端之后，就发送FIN报文给客户端了，自己进入 LAST_ACK 状态
第四次挥手：客户端在接收到服务端的FIN报文之后，回应ACK报文，自己进入 TIME_WAIT 状态。服务端收到客户端的ACK报文之后，服务端就进入 CLOSE 状态；客户端在TIME_WAIT等到2MSL，也进入了 CLOSE 状态（确保接收方收到最后的ACK报文，如果没收到，发送方会重发，就是确保能够顺利断开连接的）

假设TIME_WAIT 状态多过会有什么危害？怎么解决呢？

TIME_WAIT 状态只会出现在主动发起关闭连接的一方。危害就是会占用内存资源和端口呗（毕竟在等待嘛）怎么解决？我也不知道。

基于TCP的协议：http、https、FTP、SSH、NDS、SMTP…

UDP协议

用户数据报协议，和TCP协议一样，负责为不同终端系统的应用进程之间提供通信服务，UDP提供的是无连接的通信服务。UDP协议不会对自己提供的连接实施控制，是一种不可靠的传输层协议。

对数据分割重组
同时为多个应用程序提供传输服务
不确保数据按顺序传输
不确保接收方收到数据，并且不提供重传机制
不控制传输速率

UDP具有高速、低延时的优点。而且UDP的封装要比TCP封装要简单的多，UDP头部长度固定为8子节，TCP头部长度至少20子节。

有些应用协议在实现上即会使用TCP又会使用UDP作为传输层协议（比如QQ、微信）。

以TCP作为传输层协议的DNS主要用于数据的区域传送；

以UDP作为传输层协议的DNS则主要用于实现域名解析

总之UDP一般多用于延迟容忍度低的应用层协议

传输层的作用就是提供两台终端设备上应用进程之间的通信

TCP头部：源端口、目的端口、序列号、确认号、头部长度、控制字段（URG、ACK、SYN、FIN、RST）、窗口大小、校验和、紧急指针

UDP头部:源端口、目的端口、校验和、长度

HTTP协议

HTTP协议提供的服务是在HTTP客户端和HTTP服务器之间传输信息，他运行于TCP协议之上，HTTP访问默认使用TCP80端口，由TCP协议为HTTP信息传输提供可靠性保障以及拥塞管理等服务。因此，在客户端和服务器要通过HTTP传输信息之前，他们之间需要首先建立TCP连接。

HTTP1.0 最初不支持持续连接，当TCP连接建立起来后，客户端只能向服务器发送一次HTTP请求，当服务器用被请求的内容对该信息做出响应后，这条TCP连接就会断开。如果还需要传递其他信息则需要重新建立TCP连接。

HTTP 1.1 开始支持连续连接，就是客户端和服务器之间建立TCP连接后，可以复用这条TCP连续发送多个请求/响应消息，甚至客户端可以在前一个请求尚未收到响应消息之前就发送下一个请求消息。并且增加了TRACE（追踪路径）协议等，

HTTP2.0 ：

HTTP 协议下的消息类型：

请求消息：客户端通过这类消息向服务器请求信息
响应消息：服务器通过响应消息向客户端发送所请求的信息

无论请求消息还是响应消息，都由起始行、消息首部、消息实体组成
请求报文和响应报文的首部内容由以下数据组成

请求行：包含请求方法、请求URLI、HTTP版本
状态行：包含状态码、原因短语、HTTP版本
首部字段：通用首部、请求首部、响应首部、实体首部。(主要包含请求和响应的各种条件)
Cookie

响应状态码：

1xx （信息状态码）接受的请求正在处理
2xx （成功状态码）请求正常处理完毕
3xx (重定向状态码) 需要进行附加操作已完成请求，协商
4xx （客户端错误状态码）服务器无法处理请求
5xx （服务器错误状态码）服务器处理请求错误

代理：一种有转发功能的应用程序，相当于客户端与服务器间的中转站，接收客户端的请求，转发给其他服务器；源服务器返回的响应再通过代理服务器返回给客户端。

网关：其实是一个服务器，负责转发其他服务器通信数据，能使通信线路上的服务器提供非HTTP协议服务

隧道：使用SSL等加密手段进行通信，目的是确保客户端与服务器进行安全的通信

Cookie:

用于标识用户和状态管理的，因为http是一个无状态的协议，他不对之前的请求和相应状态进行管理。通过cookie技术可以在请求和相应报文中写入cookie信息来控制客户端的状态。cookie会根据从服务器端发送的相应报文中的set-cookie的首部字段信息，通知客户端保存Cookie.当客户端再次向服务器发送请求时，客户端会自动再请求报文中加入Cookie值后发送出去。服务器端发现客户端发送过来的Cookie后，会检查客户端的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。Cookie在一些频繁需要身份验证的网站能够给用户更高效的体验。

Session：

就是在服务器端保存的一个数据结构（相当于是一个对象）用来跟踪用户的状态，他的实现使基于Cookie的，就是通过Cookie对session的状态进行管理。session 存储的数据是在服务器端的，cookie存储在客户端，session没有数据限制，cookie有（4k左右）

HTTP缺点：

通信使用明文，内容易被窃听、不验证通信方的身份，有可能遭遇伪装、无法证明报文的完整性，报文可能遭到篡改。

HTTPS：

是在http的基础上加上加密处理和认证等机制。因此https可以对通信和内容进行加密，他通过SSL（安全套接字层）、或者TLS（安全传输层协议）的组合使用，加密HTTP的通信内容。此外HTTPS还可以对通信的内容进行加密。

SSL协议不仅提供加密处理，而且还使用了证书的验证机制，用于确定通信方的身份，证书是第三方机构颁发的，SSL的加密算法使公开的，密钥是保密的
HTTPS也是有缺点的：加密通信他会消耗更多的cpu和内存资源，通信速度比较慢。

常见web攻击技术

SQL注入攻击：通过注入非法的SQL语句对数据库进行一些增删查改的操作：非法篡改用户信息，
OS命令注入攻击：通过web应用执行非法的操作系统命令，达到攻击的目的。
http首部注入攻击：通过在首部字段内插入换行（设置虚拟的Cookie信息，重定向URI），向首部主体内添加内容
会话劫持：通过窃听、XSS攻击盗取会话ID，非法使用会话ID伪装成用户，达到攻击目的。
XSS攻击：跨站脚本攻击，通过在网页里插入恶意可执行的脚本代码，当用户浏览该页之时，嵌入网页的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。比如通过js脚本调用document.cookie窃取Cookie信息，然后伪装成用户。这个攻击主要是通过插入脚本代码实现的，我们可以把左右尖括号用转义字符&It&gt代替，通过正则匹配来实现。
CSRF攻击：跨站点请求伪造攻击。通过设置陷阱（在网页中植入其他的链接）骗取已经验证过身份的用户执行一些需要用户权限才能完成的操作。防护：进行需要权限的操作时需要用户提供验证码、服务器生成一个跨站点请求的token，客户端(浏览器) 提交表单中含有 CSRF token 信息；服务端接收 CSRF token 并验证其有效性、