目录
1、OSI(Open System Interconnection) 七层模型 TCP/IP五层协议
1、OSI(Open System Interconnection) 七层模型 TCP/IP五层协议
应用层：网络服务与最终用户的一个接口；手机、电脑这些设备都属于应用层
表示层：数据的表示、安全、压缩；（五层模型中合并到应用层）
会话层：建立、管理、终止会话；（五层模型中合并到应用层）
传输层：定义传输数据的协议端口号，以及流程和差错校验；
网络层：进行逻辑地址寻址，实现不同网络之间的路径选择；
数据链路层：建立逻辑链接 、进行硬件地址寻址、差错校验等功能（由底层网络定义协议）
物理层：建立、维护、断开物理连接（由底层网络定义协议）；
TCP/IP协议的工作流程如下：
- 1.在源主机上，应用层将一串应用数据流传送给传输层。
- 2.传输层将应用层的数据流截成分组，并加上TCP报头形成TCP段，送交网络层。
- 3.在网络层给TCP段加上包括源、目的主机IP地址的IP报头，生成一个IP数据包，并将IP数据包送交链路层。
- 4.链路层在其MAC帧的数据部分装上IP数据包，再加上源、目的主机的MAC地址和帧头，并根据其目的MAC地址，将MAC帧发往目的主机或IP路由器。
- 5.在目的主机，链路层将MAC帧的帧头去掉，并将IP数据包送交网络层。
- 6.网络层检查IP报头，如果报头中校验和与计算结果不一致，则丢弃该IP数据包；若校验和与计算结果一致，则去掉IP报头，将TCP段送交传输层。
- 7.传输层检查顺序号，判断是否是正确的TCP分组，然后检查TCP报头数据。若正确，则向源主机发确认信息；若不正确或丢包，则向源主机要求重发信息。
- 8.在目的主机，传输层去掉TCP报头，将排好顺序的分组组成应用数据流送给应用程序。这样目的主机接收到的来自源主机的字节流，就像是直接接收来自源主机的字节流一样
2、HTTP协议、HTTPS协议
HTTP协议是基于TCP协议实现的，它是一种超文本传输协议，它指定了客户端可能发送什么样的消息以及得到怎么样的响应。主要负责点对点之间的通信
超文本就是用超链接的方式，将各种不同空间的文字信息组织在一起的网状文本
HTTP2基于TCP协议
HTTP3基于UDP协议
HTTP协议存在的问题：
1） HTTP报文使用明文方式发送，内容可能被窃听
2）无法证明报文的完整性
3）不验证通信方的身份
HTTPS协议在HTTP的基础上建立SSL加密层，并对传输数据进行加密
端口号
用来标识一台主机的不同进程
| HTTP | HTTPS | |
| 端口号 | 80 | 443 |
常见的HTTP状态码
| 1xx | 信息类，表示请求已接收 继续处理（临时响应） |
| 2xx | 成功类，操作被成功接收并处理 |
| 3xx | 重定向，需要进一步操作以完成请求 |
| 4xx | 客户端错误，请求包含语法错误或无法完成请求 |
| 5xx | 服务器错误，服务器在处理请求的过程中发生错误 |
403：服务器拒绝执行客户端的请求
404：服务器找不到客户端所请求的资源
304：所请求的资源并未修改（命中协商缓存）
3、HTTP请求
HTTP协议中定义了浏览器和服务器进行交互的不同方法，基本方法有四种：GET、POST、PUT、DELETE。（可以理解为对服务器资源的查、删、改、增）
1）GET：向数据库发索取数据的请求，从而获取信息，该请求类似于数据库中的select操作，不会影响资源的内容，即该请求不会对资源产生副作用；
2）POST：向服务端发送数据，类似于数据库中的insert操作，会创建新的内容；目前几乎所有的提交操作都是用POST请求
3）PUT：向服务端发送数据从而改变信息，类似于数据库的update操作，用来修改数据的内容，但不会增加数据
4）DELETE：删除服务器数据的过程
get请求和post请求的区别
① get请求参数通过URL传递，post请求放在Request body中
② get请求比post请求更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息；（get也可以加上request body，post请求带上url参数）
③ 对于参数类型，get请求只接受ASCII字符，而post请求没有限制
④ get请求在URL中传送的参数是有长度限制的，最多2058字节；post请求没有限制
⑤ get请求的参数会被完整保留在浏览器历史记录中；post请求中的参数不会被保留
⑥ get请求只能进行URL编码；post请求支持多种编码方式
⑦ get请求会被浏览器主动cache（缓存）；post请求不会被缓存
⑧ get请求产生的URL地址可收藏为书签；post请求不可以
⑨ get在浏览器回退时是无害的；post会再次提交请求
4、TCP和UDP
| UDP | TCP | |
|---|---|---|
| 是否连接 | 无连接（发送数据之前不需要建立连接 | 面向连接 |
| 是否可靠 | 不可靠传输，不使用流量控制和拥塞控制 | 可靠传输，使用流量控制和拥塞控制 |
| 连接对象个数 | 支持一对一、一对多、多对一、多对多 | 只支持一对一通信 |
| 传输方式 | 面向报文 | 面向字节流 |
| 首部开销 | 首部开销小，仅8字节 | 最小20字节，最大60字节 |
| 适用场景 | 实时应用 | 要求可靠传输的应用 |
| 保证数据正确性和数据顺序 | 可能丢包且不保证数据顺序 |
TCP报文结构
字段解释：
序号（seq）：本报文段所发送的数据的第一个字节的序号
确认号（ack）：期望收到对方的下一个报文段的数据的第一个字节的序号；若确认号为N，则表明序号N-1为止所有的数据都已正确收到
【确认位ACK】：只有当ACK=1时确认号字段才有效；ACK=0时，确认号无效；TCP规定，在连接建立后所有传送的报文段都必须把ACK置1
【同步位SYN】：SYN=1表示这是一个连接请求或连接接收报文；SYN=1,ACK=0:表明这是一个连接请求报文，对方若同意建立连接，则在响应报文中使用SYN= 1, ACK=1。
【终止位FIN】：用来释放一个连接。FIN=1表明此报文段的发送方的数据已发送完毕了并要求释放传输连接。
URG(紧急) 当URG=1,表明紧急指针字段有效，该报文段有紧急数据，应尽快发送。
PSH(推送) 接收方接收到PSH=1的报文段，会尽快交付接收应用进程，不再等待整个缓存填满再交付。实际较少使用。
RST(复位) RST=1时，表明TCP连接中出现严重差错，必须是否连接，再重连。
TCP三次握手
第一次握手：客户端的TCP进程创建一个传输控制块TCB，然后向服务器发出连接请求报文段，同步位SYN置为1，随机初始化一个序列号seq=x，客户端进入SYN_SENT（同步已发送）状态
第二次握手：服务器收到连接请求报文段，如果同意连接，则向客户端发送确认，确认报文段中同步位SYN=1，确认位ACK=1，确认号ack=x+1，同时为自己随机初始化一个序列号seq=y，服务器进入SYN_RCVED状态
第三次握手：客户端收到服务器的确认以后，再向服务器发出确认。确认报文ACK=1，确认号ack=y+1.客户端进入ESTAB_LISHED状态；服务器收到客户端的确认后也进入ESTAB_LISHED状态。连接建立完成
三次握手的原因：
1）防止重复连接
比如在网络状况比较复杂或者网络状况比较差的情况下，发送方可能会连续发送多次建立连接的请求。如果 TCP 握手的次数只有两次，那么接收方只能选择接受请求或者拒绝接受请求，但它并不清楚这次的请求是正常的请求，还是由于网络环境问题而导致的过期请求，如果是过期请求的话就会造成错误的连接。所以如果 TCP 是三次握手的话，那么客户端在接收到服务器端 SEQ+1 的消息之后，就可以判断当前的连接是否为历史连接，如果判断为历史连接的话就会发送终止报文（RST）给服务器端终止连接；如果判断当前连接不是历史连接的话就会发送指令给服务器端来建立连接。
2）同步初始化序列号
如果是两次握手的话，只有客户端其实序列号能被确认，服务器端的序列号则得不到确认，因此也就无法得到一个可靠的序列号了，所以 TCP 连接至少需要三次握手。
TCP 连接还可以四次握手，甚至是五次握手，也能实现 TCP 连接的稳定性，但三次握手是最节省资源的连接方式，因此 TCP 连接应该为三次握手。
TCP四次挥手
第一次挥手：客户端先发送连接释放报文段，段首部的终止控制位FIN=1，序号seq=u（客户端前面发送数据的最后一个序号加一）；客户端进入FIN-WAIT-1（终止等待1）状态，等待服务器的确认；
第二次挥手：服务器收到客户端的连接释放报文段后，立刻发出确认报文段，确认号ack=u+1，序列号seq=v（服务器前面发送数据的最后一个序号加一），然后服务器进入CLOSE-WAIT（关闭等待）状态；
第三次挥手：客户端收到服务器的确认报文段后进入到FIN-WAIT-2（终止等待2）状态，继续等待服务器发出连接释放报文段：
若服务器已经没有数据要发送，服务器就会向客户端发送连接释放报文段，段首部的终止控制位FIN=1,序号seq=w（版关闭状态可能有发送了一些数据），确认号ack=u+1，这时服务器进入LAST-ACK（最后确认）状态，等待客户端确认；
第四次挥手：客户端收到服务器的连接释放报文段并发出确认，确认段中 确认位ACK=1，确认号ack=w+1，序号seq=u+1，然后客户端进入TIME-WAIT（时间等待）状态，当服务器再接收到该确认段后，服务器进入CLOSED状态
2433
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
