写作认知体系
  • 《技能记录》
  • 协议
samy
2014-02-01

常用网络协议关系

# 计算机体系结构

# 各协议比较及细分

# 协议群

数据链路层、物理层 ：物理设备 (在五层模型中能称之为协议的都在三层以上)

  • 网络层：
    • IP 协议：寻址通过路由器查找，将消息发送给对方路由器，通过 ARP 协议,发送自己的mac地址
    • ARP 协议：Address Resolution Protocol 从 ip 地址获取 mac地址 （局域网）； 根据目的 IP 地址，解析目的 mac 地址；
  • 传输层：TCP 、 UDP
  • 应用层: HTTP 、 DNS 、 FTP 、 TFTP 、 SMTP 、 DHCP

# ARP协议

根据目的 IP 地址，解析目的 mac 地址；

image-20211104193135316

有了源mac地址和目标mac地址，就可以传输数据包了；

# DHCP协议

通过 DHCP 自动获取网络配置信息 （动态主机配置协议Dynamic Host Confifiguration Protocol）我们无需自己手动配置 IP；

# DNS协议

DNS 是Domain Name System的缩写， DNS 服务器进行域名和与之对应的 IP 地址转换的服务器

  • 顶级域名 .com 、
  • 二级域名 .com.cn 、 三级域名 www.zf.com.cn , 有多少个点就是几级域名

访问过程：我们访问 zf.com.cn

  • 操作系统里会对 DNS 解析结果做缓存，如果缓存中有直接返回 IP 地址
  • 查找 C:\WINDOWS\system32\drivers\etc\hosts 如果有直接返回 IP 地址
  • 通过 DNS 服务器查找离自己最近的根服务器，通过根服务器找到 .cn 服务器，将 ip
  • 返回给 DNS 服务器
  • DNS 服务器会继续像此 ip 发送请求，去查找对应 .cn 下 .com 对应的 ip ...获取最终的 ip 地址。缓存到 DNS 服务器上；
  • 获取最终的 ip 地址。缓存到 DNS 服务器上；【DNS 服务器会对 ip 及 域名 进行缓存】

image-20211104193633341

# 体系结构与协议群

OSI的体系结构详细介绍 ==>应传网接

  • 网络七层模型是一个标准，而非实现。
  • 网络四层模型是一个实现的应用模型。网络四层模型由七层模型简化合并而来。

# 分层管理

各层比较

路由器与交换机的区别

# 通信过程

image-20211104200553675

# 地址

通信是通过 ip 地址查找对应的 mac 来进行通信的。 IP地址 是可变的（类似我们收

件地址）MAC地址是不可变的。

# IP地址

IPV4 网际协议版本4 ，地址由 32 位二进制数值组成 例如：192.168.1.1 ，大概42亿个

IPV6 网际协议版本6 ，地址由 8个16位块的128位组成。 例如：

2408:8207:788b:2370:9530:b5e7:9c53:ff87 大约 3.4*10^38

# MAC地址

设备通信都是由内部的网卡设备来进行的，每个网卡都有自己的mac地址（原则上唯一）

# 物理设备

# 物理层

中继器：双绞线最大传输距离 100M ，中继器可以延长网络传输的距离，对衰减的信

号有放大在生的功能。

集线器：多口的中继器，目的是将网络上的所有设备连接在一起 , 不会过滤数据，也

不知道将收到的数据发给谁。（采用的方式就是广播给每个人）

可以实现局域网的通信，但是会有安全问题，还会造成不必要的流量浪费。 傻，你

就不能记住来过的人嘛？每次都发送？

# 数据链路层

交换机：交换机可以识别已经连接设备的物理地址（MAC地址）。可以将数据传递到

相应的端口上

# 网络层

路由器：

检测数据的 ip 地址是否属于自己网络，如果不是会发送到另一个网络。没有 wan 口的路由器可以看成交换机。 路由器一般充当网关，路由器会将本地 IP 地址进行NAT

网关：

两个子网之间不可以直接通信，需要通过网关进行转发

image-20211104192022627

# TCP/UDP/HTTP协议比较

# TCP/UDP协议

Transmission Control Protocol，TCP即 传输控制协议

  1. 属于 传输层通信协议
  2. 基于TCP的应用层协议有HTTP、SMTP、FTP、Telnet 和 POP3

关于TCP的其他知识：如三次握手、四次挥手、无差错控制原理等

User Datagram Protocol，UDP即 用户数据报协议

  1. 属于 传输层通信协议
  2. 基于UDP的应用层协议有 TFTP、SNMP 与 DNS

# TCP报文段格式

  • TCP虽面向字节流，但传送的数据单元 = 报文段
  • 报文段 = 首部 + 数据 2部分
  • TCP的全部功能体现在它首部中各字段的作用，故下面主要讲解TCP报文段的首部
  1. 首部前20个字符固定、后面有4n个字节是根据需而增加的选项
  2. 故 TCP首部最小长度 = 20字节

image-20211104194043106

  • 源端口号、目标端口号，指代的是发送方随机端口，目标端对应的端口
  • 序列号：32位序列号是用于对数据包进行标记，方便重组
  • 确认序列号：期望发送方下一个发送的数据的编号
  • 4位首部长度：单位是字节，4位最大能表示15，所以头部长度最大为60
  • URG :紧急新号、 ACK :确认信号、 PSH :应该从TCP缓冲区读走数据、 RST ：断开重新
  • 连接、 SYN :建立连接、 FIN :表示要断开
  • 窗口大小： 当网络通畅时将这个窗口值变大加快传输速度，当网络不稳定时减少这个
  • 值。在TCP中起到流量控制作用。
  • 校验和：用来做差错控制，看传输的报文段是否损坏
  • 紧急指针：用来发送紧急数据使用

TCP 对数据进行分段打包传输，对每个数据包编号控制顺序。

# UDP报文段格式

  • UDP的报文段共有2个字段：数据字段 & 首部字段
  • 下面主要介绍首部（8字节、4个字段）

image-20211104195216236

使用场景： DHCP 协议、 DNS 协议、 QUIC 协议等 (处理速度快，可以丢包的情况)

# TCP/UDP协议的区别【要点】

TCP有粘包的情况；

协议 连接性 双工性 可靠性 有序性 有界性 拥塞控制 传输速度 量级 头部大小
TCP 面向连接(Connection oriented) 全双(1:1) 可靠(重传机制) 有序(通过SYN排序) 无, 有粘包情况 有 慢 低 20~60字节
UDP 无连接(Connection less) n:m 不可靠(丢包后数据丢失) 无序 有消息边界, 无粘包 无 快 高 8字节

# TCP粘包/拆包

详细可见【Websocket的使用】中的详细介绍；

  • Nagle 算法的基本定义是任意时刻，最多只能有一个未被确认的小段 (TCP内部控制)
  • Cork算法 当达到 MSS (Maximum Segment Size )值时统一进行发送（此值就是帧的大小 -ip 头 - tcp 头 = 1460个字节）理论值
# 简介

当一次发送数据过长时，tcp 会把数据封成多个包发送；同样当数据过短时， 会把数据合并成一个包发送，这种现象就是粘包。

默认情况下, TCP 连接会启用延迟传送算法 (Nagle 算法), 在数据发送之前缓存他们. 如果短时间有多个数据发送, 会缓冲到一起作一次发送 (缓冲大小见 socket.bufferSize), 这样可以减少 IO 消耗提高性能.如果是传输文件的话, 那么根本不用处理粘包的问题, 来一个包拼一个包就好了. 但是如果是多条消息, 或者是别的用途的数据那么久需要处理粘包.

可以参见网上流传比较广的一个例子:

连续调用两次 send 分别发送两段数据 data1 和 data2, 在接收端有以下几种常见的情况:

  • A. 先接收到 data1, 然后接收到 data2 .
  • B. 先接收到 data1 的部分数据, 然后接收到 data1 余下的部分以及 data2 的全部.
  • C. 先接收到了 data1 的全部数据和 data2 的部分数据, 然后接收到了 data2 的余下的数据.
  • D. 一次性接收到了 data1 和 data2 的全部数据.

其中的 BCD 就是我们常见的粘包的情况. 而对于处理粘包的问题, 常见的解决方案有:

  • 多次发送之前间隔一个等待时间；
  • 关闭 Nagle 算法；
  • 进行封包/拆包；封包/拆包是目前业内常见的解决方案了. 即给每个数据包在发送之前, 于其前/后放一些有特征的数据, 然后收到数据的时候根据特征数据分割出来各个数据包.
# 解决方案

  • 方案1

    只需要等上一段时间再进行下一次 send 就好, 适用于交互频率特别低的场景. 缺点也很明显, 对于比较频繁的场景而言传输效率实在太低. 不过几乎用做什么处理.

  • 方案2

    关闭 Nagle 算法, 在 Node.js 中你可以通过 `socket.setNoDelay() (opens new window) 方法来关闭 Nagle 算法, 让每一次 send 都不缓冲直接发送.

    该方法比较适用于每次发送的数据都比较大 (但不是文件那么大), 并且频率不是特别高的场景. 如果是每次发送的数据量比较小, 并且频率特别高的, 关闭 Nagle 纯属自废武功.

    另外, 该方法不适用于网络较差的情况, 因为 Nagle 算法是在服务端进行的包合并情况, 但是如果短时间内客户端的网络情况不好, 或者应用层由于某些原因不能及时将 TCP 的数据 recv, 就会造成多个包在客户端缓冲从而粘包的情况. (如果是在稳定的机房内部通信那么这个概率是比较小可以选择忽略的)

  • 方案3

    封包/拆包是目前业内常见的解决方案了. 即给每个数据包在发送之前, 于其前/后放一些有特征的数据, 然后收到数据的时候根据特征数据分割出来各个数据包.

    • 1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度;
    • 2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充）【推荐】
    • 3、可以在数据包之间设置边界，如添加特殊符号

    示例：

    //当前发送方发送了两个包，两个包的内容如下：
123456789
ABCDEFGH

//粘包情况
123456789ABCDEFGH
//分包情况
12345
6789
ABCDE
FGH

//处理办法：
//给数据包的头尾加上标记
START123456789END
STARTABCDEFGHEND
//在数据包头部加上内容的长度
PACKAGELENGTH:0009123456789
PACKAGELENGTH:0008ABCDEFGH
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19

# 滑动窗口

  • 滑动窗口：TCP是全双工的，所以发送端有发送缓存区；接收端有接收缓存区，要发送的数据都放 到发送者的缓存区，发送窗口（要被发送的数据）就是要发送缓存中的哪一部分
  • 核心是流量控制：在建立连接时，接收端会告诉发送端自己的窗口大小（ rwnd ）,每次接收端收到数据后都会再次确认（ rwnd ）大小，如果值为0，停止发送数据。（并发送窗口探测包，持续监测窗口大小）

# TCP拥塞处理 （队头阻塞，慢启动， 短连接）

举例：假设接收方窗口大小是无限的，接收到数据后就能发送 ACK 包，那么传输数据主要是依赖于网络带宽，带宽的大小是有限的。

  • TCP 维护一个拥塞窗口 cwnd （congestion window）变量 ，在传输过程正没有拥塞就将此值增大。如果出现拥塞（超时重传 RTO(Retransmission TimeOut) ）就将窗口值减少。
  • cwnd < ssthresh 使用慢开始算法
  • cwnd > ssthresh 使用拥塞避免算法
  • ROT时更新 ssthresh 值为当前窗口的一半，更新 cwnd = 1
  • 传输轮次： RTT (Round-trip time) ,从发送到确认信号的时间
  • cwnd 控制发送窗口的大小。

快重传，可能在发送的过程中出现丢包情况。此时不要立即回退到慢开始阶段，而是对已经收到的报文重复确认，如果确认次数达到3此，则立即进行重传 快恢复算法(减少超时重传机制的出现)，降低重置 cwnd 的频率。

image-20211104195731593

image-20211104195749413

# HTTP协议

# HTTP报文结构

HTTP的请求报文由 请求行、请求头 & 请求体 组成，如下图

以 nc 模拟 http 报文如下

$ nc www.baidu.com 80
GET / HTTP/1.1
Host: www.baidu.com

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 14615
Content-Type: text/html
Date: Tue, 10 Dec 2019 02:48:44 GMT
P3p: CP=" OTI DSP COR IVA OUR IND COM "
P3p: CP=" OTI DSP COR IVA OUR IND COM "
Pragma: no-cache
Server: BWS/1.1
Set-Cookie: BAIDUID=F0FC6B3A056DEA285F51A1F2F8A170BB:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BIDUPSID=F0FC6B3A056DEA285F51A1F2F8A170BB; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: PSTM=1575946124; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BAIDUID=F0FC6B3A056DEA287CB2B9422E09E30E:FG=1; max-age=31536000; expires=Wed, 09-Dec-20 02:48:44 GMT; domain=.baidu.com; path=/; version=1; comment=bd
Traceid: 1575946124058431156210725656341129791126
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1

<!DOCTYPE html><!--STATUS OK-->
........内容省略
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# TCP/UDP

# 建立连接过程

  • TCP建立连接需 三次握手
  • 具体介绍如下

成功进行TCP的三次握手后，就建立起一条TCP连接，即可传送应用层数据

  1. 因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据
  2. 三次握手期间，任何1次未收到对面的回复，则都会重发

特别说明：为什么TCP建立连接需三次握手, 两次不可以么？

“三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。

防止服务器端因接收了早已失效的连接请求报文，从而一直等待客户端请求，最终导致形成死锁、浪费资源；

详细分析：

  • 正常的情况：A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B。没有 “已失效的连接请求报文段”。

  • 现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就向 A 发出确认报文段，同意建立连接。

    假设不采用“三次握手”，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立，并一直等待 A 发来数据。这样，B 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

# 释放连接过程

  • 在通信结束后，双方都可以释放连接，共需 四次挥手

  • 具体如下

延伸疑问：为什么客户端关闭连接前要等待2MSL时间？

  1. 即 TIME - WAIT 状态的作用是什么；
  2. MSL = 最长报文段寿命（Maximum Segment Lifetime）

原因1：为了保证客户端发送的最后1个连接释放确认报文 能到达服务器，从而使得服务器能正常释放连接;

为了防止最终的 ACK 丢失，发送 ACK 后需要等待一段时间，因为如果丢包服务端需要重新发送 FIN 包，如果客户端已经 closed ，那么服务端会将结果解析成错误。从而在高并发非长连接的场景下会有大量端口被占用。

# 为什么TCP释放连接需四次挥手？

  • 结论: 为了保证通信双方都能通知对方 需释放 & 断开连接

    **TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。**TCP 是全双工模式，这就意味着，当 A 向 B 发出 FIN 报文段时，只是表示 A 已经没有数据要发送了，而此时 A 还是能够接受到来自 B 发出的数据；B 向 A 发出 ACK 报文段也只是告诉 A ，它自己知道 A 没有数据要发了，但 B 还是能够向 A 发送数据。

    所以想要愉快的结束这次对话就需要四次挥手。即释放连接后，都无法接收 / 发送消息给对方

# 为什么建立连接协议是三次握手，而关闭连接却是四次挥手呢？

普通原理：

  • 防止服务器端因接收了早已失效的连接请求报文，从而一直等待客户端请求，最终导致形成死锁、浪费资源；【三次握手】

  • 为了保证通信双方都能通知对方 需释放 & 断开连接【四次挥手】

内部原理：

三次握手：这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。

四次挥手：当关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET, 也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

# 过程总括【要点】

# TCP 三次握手的过程：

  • 客户端发送一个带 SYN=1，Seq=X 的数据包到服务器端口（第一次握手，由浏览器发起，告诉服务器我要发送请求了）
  • 服务器发回一个带 SYN=1， ACK=X+1， Seq=Y 的响应包以示传达确认信息（第二次握手，由服务器发起，告诉浏览器我准备接受了，你赶紧发送吧）
  • 客户端再回传一个带 ACK=Y+1， Seq=Z 的数据包，代表“握手结束”（第三次握手，由浏览器发送，告诉服务器，我马上就发了，准备接受吧）

# TCP 四次挥手的过程：

  • 发起方向被动方发送报文，Fin、Ack、Seq，表示已经没有数据传输了。并进入 FIN_WAIT_1 状态。(第一次挥手：由浏览器发起的，发送给服务器，我请求报文发送完了，你准备关闭吧)
  • 被动方发送报文，Ack、Seq，表示同意关闭请求。此时主机发起方进入 FIN_WAIT_2 状态。(第二次挥手：由服务器发起的，告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧)
  • 被动方向发起方发送报文段，Fin、Ack、Seq，请求关闭连接。并进入 LAST_ACK 状态。(第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧)
  • 发起方向被动方发送报文段，Ack、Seq。然后进入等待 TIME_WAIT 状态。被动方收到发起方的报文段以后关闭连接。发起方等待一定时间未收到回复，则正常关闭。(第四次挥手：由浏览器发起，告诉服务器，我响应报文接受完了，我准备关闭了，你也准备吧)

# 图示

image-20211104194424019image-20211104194439817image-20211104194451911

tcp三次连接：

  • 1）我能主动给你打电话吗？
  • 2）当然可以啊！那我也能给你打电话吗？
  • 3）可以的呢，建立连接成功！

Tcp四次挥手

  • 1）我们分手吧
  • 2）收到分手的信息
  • 3）好吧，分就分吧
  • 4）行，那就到这里了

# 通俗图示

# TCP 协议保证传输的可靠性

TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。

对于可靠性，TCP通过以下方式进行保证：

  • 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
  • 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
  • 丢弃重复数据：对于重复数据，能够丢弃重复数据；
  • 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
  • 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
  • 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

# 问题

# DDos防御

# 客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？

答：服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认

(1). DDos 攻击：

  • 客户端向服务端发送请求链接数据包
  • 服务端向客户端发送确认数据包
  • 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

(2). DDos 预防：（没有彻底根治的办法，除非不使用TCP）

  • 限制同时打开SYN半链接的数目
  • 缩短SYN半链接的Time out 时间
  • 关闭不必要的服务

# 接口(DDOS)防御

  1. 网关控制流量洪峰，对在一个时间段内出现流量异常，可以拒绝请求;
  2. 源ip请求个数限制。对请求来源的ip请求个数做限制;
  3. 频率限制（1s内接口调用次数限制）IP限制； 防刷一般分两种：
  • 总调用次数受限制。这个一般是在后端做限制，单位时间内最多可调用次数。
  • 同一客户端次数限制。这个前端的一般使用是给接口调用加锁，在返回结果或者一定时间之后解锁。

刷接口直接走脚本，前端限制有一定作用，但不大。

  • 根据IP限制调用次数【请求在代理服务器被拦截nginx，减少后端服务被调用】；
  • 拦截器特定信息校验，例如：token【后端服务器拦截器，减少业务判断和处理】； 1、校验请求头referer 2、校验请求token； 3、请求频率

# Socket

  • 即套接字，是应用层 与 TCP/IP 协议族通信的中间软件抽象层，表现为一个封装了 TCP / IP协议族 的编程接口（API）
  1. Socket不是一种协议，而是一个编程调用接口（API），属于传输层（主要解决数据如何在网络中传输）
  2. 即：通过Socket，我们才能在Andorid平台上通过 TCP/IP协议进行开发
  3. 对用户来说，只需调用Socket去组织数据，以符合指定的协议，即可通信

  • 成对出现，一对套接字：Socket ={(IP地址1:PORT端口号)，(IP地址2:PORT端口号)}

  • 一个 Socket 实例 唯一代表一个主机上的一个应用程序的通信链路

# 原理

Socket的使用类型主要有两种：

  • 流套接字（streamsocket） ：基于 TCP协议，采用 流的方式 提供可靠的字节流服务
  • 数据报套接字(datagramsocket)：基于 UDP协议，采用 数据报文 提供数据打包发送的服务

具体原理图如下：

两类型比较

# 实践

# TCP抓包

image-20211104194231564

# UDP抓包

image-20211104195421249

# etag项目

socket模式下tcp/udp通讯：应用于iot中的etag项目

etag电子标签的协议流程步骤：

# 写一个简易的 WebServer

一个简易的 Server 的流程如下：

  • 1.建立连接，接受一个客户端连接。
  • 2.接受请求，从网络中读取一条 HTTP 请求报文。
  • 3.处理请求，访问资源。
  • 4.构建响应，创建带有 header 的 HTTP 响应报文。
  • 5.发送响应，传给客户端。

省略流程 3，大体的程序与调用的函数逻辑如下：

  • socket() 创建套接字
  • bind() 分配套接字地址
  • listen() 等待连接请求
  • accept() 允许连接请求
  • read()/write() 数据交换
  • close() 关闭连接

# Socket 与 Http 对比

  • Socket属于传输层，因为 TCP / IP协议属于传输层，解决的是数据如何在网络中传输的问题
  • HTTP协议 属于 应用层，解决的是如何包装数据

由于二者不属于同一层面，所以本来是没有可比性的。但随着发展，默认的Http里封装了下面几层的使用，所以才会出现Socket & HTTP协议的对比：（主要是工作方式的不同）：

  • Socket：采用 服务器主动发送数据 的方式
  1. 即建立网络连接后，服务器可主动发送消息给客户端，而不需要由客户端向服务器发送请求
  2. 可理解为：是服务器端有需要才进行通信
  • Http：采用 请求—响应 方式。
  1. 即建立网络连接后，当 客户端 向 服务器 发送请求后，服务器端才能向客户端返回数据。
  2. 可理解为：是客户端有需要才进行通信

# TCP/IP和DNS与HTTP的密切关系

上次更新: 2022/04/15, 05:41:29
react-dnd用法详解
http协议相关

← http协议相关→

Copyright © 2015-2022 友一升 | yessz
×