子网
子网地址
- 一个ip地址分为子网地址和主机地址两部分
- 子网地址 = ip地址和掩码进行与运算
相同子网的两个判定条件
- 子网地址相同
- 直接相连,没有中间路由器
网关
- 默认网关: 通往外部网络的第一跳路由器
模型
OSI七层
- 分层
- 应用层
- 表示层
- 会话层: RPC, SQL,ASP
- 传输层
- 网络层
- 数据链路层
- 物理层
TCP/IP五层模型
- 分层
- 应用层: SMTP,TELNET,DNS,HTTP
- 传输层: TCP/UDP、TLS
- 网络层: ICMP,IP,ARP
- 数据链路层: mac地址,以太网,ARP,PPP(Point to Point Protocol)
- 物理层
- 参考
TCP(传输控制协议)
特性
- 可靠性:只要不得到确认,就重新发送数据报,直到得到对方的确认为止
- 参考:Python 绝技 —— TCP 服务器与客户端 | Secrypt Agency
三次握手与四次挥手
- 状态机:
- 三次握手过程:
- client发送连接请求报文,seq=x
- server接受连接后回复ACK=x+1,seq=y ,并为此处连接分配资源
- client接收到ACK报文后,回复ACK=y+1
- 四次挥手过程:
- client发送FIN,seq=x
- server发送ACK=x+1
- server发送FIN
- client发送ACK
- 参考
滑动窗口
- 接收方需要确认发送方发送的数据包
- 分为发送方滑动窗口,和接受方滑动窗口。
- 发送方滑动窗口
- 已发送已确认
- 已发送未确认
- 未发送可发送 (2+3的大小未advertised window)
- 未发送不可发送
- 接受方滑动窗口
- 已接受已确认
- 等待接受未确认(advertised window)大小等于接收方发送的tcp头部的window size
- 不可接受
拥塞窗口
- 发送端定义
- CWND(congestion window)
- 发送端最大的发送范围等于Min(拥塞窗口,滑动窗口)
- 拥塞窗口会动态地随着网络情况的变化进行调整
- 大体策略为: 如果没有拥塞,则扩大窗口大小,否则就减小。
一台机器上最多能创建多少个TCP连接
在内存、文件句柄足够的话可以创建的连接是没有限制的(每个TCP连接至少要消耗一个文件句柄)
- 参考: 到底一台服务器上最多能创建多少个TCP连接 | plantegg
TCP和UDP的区别
连接与无连接
- TCP: 是一种面向连接的协议。在发送数据之前,必须先建立一个连接(称为“三次握手”)。在通信过程中,TCP确保双方之间建立的连接保持稳定,直到通信完成。
- UDP: 是一种无连接的协议。它不需要在发送数据前建立连接,也不保证发送的数据包会到达目标,因此通信效率较高,但可靠性较低。
可靠性
- TCP: 提供可靠的数据传输。它确保所有的数据包都能够按顺序到达,并且如果有任何数据包丢失,TCP会负责重发。这种机制使得TCP适合需要高可靠性的数据传输,比如文件传输、电子邮件、网页浏览等。
- UDP: 不保证数据包的可靠传输。它不提供重传机制,也不保证数据包按顺序到达,因此如果数据丢失,UDP不会通知发送方。UDP适用于对丢包不敏感的应用场景,比如实时音视频传输、在线游戏等。
流量控制和拥塞控制
- TCP: 提供流量控制和拥塞控制机制。这意味着发送方会根据接收方的处理能力以及网络状况调整发送速率,避免网络过载。TCP使用滑动窗口、慢启动等机制来优化网络传输性能。
- UDP: 不提供流量控制和拥塞控制。UDP会尽最大努力发送数据包,不管接收方是否能够处理,也不关心网络是否拥挤。
数据传输方式
- TCP: 以字节流的形式传输数据。TCP把应用层的数据分割成合适大小的段,并确保它们按顺序到达目标应用层。TCP的字节流传输方式使得应用层收到的数据是连续的、完整的。
- UDP: 以数据报的形式传输数据。每个UDP包是独立的,接收方收到的可能是独立且无顺序的多个数据报文。由于UDP没有确保顺序到达的机制,因此数据包可能会乱序、丢失或重复。
开销
- TCP: 由于需要建立连接、保证可靠传输以及提供流量控制,TCP的开销较大。TCP头部包含20字节的控制信息(例如序号、确认号、窗口大小等)。
- UDP: 相对来说,UDP的开销较小。它的头部只有8字节,包含了必要的端口信息和校验和字段。由于不需要建立连接或管理重传,UDP的通信效率更高。
使用场景
- TCP: 适用于需要高可靠性、数据完整性和传输顺序的场景。例如:
- 文件传输(如FTP)
- 网页浏览(HTTP/HTTPS)
- 电子邮件传输(SMTP)
- UDP: 适用于对传输速度要求高且对数据丢失不敏感的场景。例如:
- 实时音视频传输(如VoIP、视频会议)
- 在线游戏
- DNS查询
- 流媒体播放
- TCP: 适用于需要高可靠性、数据完整性和传输顺序的场景。例如:
HTTP / HTTPS
HTTP缓存机制
分类
- 强缓存
- 协商缓存
响应头
Expires
- HTTP/1
Last-Modified
/If-Modified-Since
- HTTP/1
- 流程
- 浏览器第一次访问资源,服务器会 Response Header 里添加 Last-Modified 的值
- 浏览器在下一次请求这个资源的时候,检测到有
Last-Modified
这个 Header。浏览器就会在Request中加上If-Modified-Since
,If-Modified-Since
的值就是 Last-Modified 的值 - 服务器收到请求后,如果资源没有修改,服务器返回 304 Not Modified 状态码,并且不包含资源的内容。浏览器此时会使用本地缓存中的资源。
- 如果资源发生了修改,服务器会返回新的资源内容和更新后的 Last-Modified。
Cache-Control
- HTTP/1.1
- 优先级比 Expires 要高
- 可选值
- public
- private
- no-store: 完全禁用缓存,资源不会存储在缓存中。
- no-cache: 告诉浏览器要使用缓存文件,但是每次需要跟服务器确认是最新文件以后才能用,一般使用 Etag 或者 Last-Modified 字段来控制缓存
- max-age=60
ETag
/If-None-Match
- HTTP/1.1
- ETag由服务器生成,三种方式:基于内容 / 基于版本 / 自定义生成
- 浏览器在下一次加载资源向服务器发送请求时,会将上一次返回的
Etag
值放到request header里的If-None-Match
里 - ETag 的优先级要高于 Last-Modified
缓存控制策略的优先级
- Cache-Control 优先于 Expires
参考
常见的HTTP状态码
- 分类:
- 1 表示消息
- 2 表示成功
- 3 表示重定向
- 4 表示请求错误
- 5 表示服务器错误
- 常见
- 200: OK. 服务器已成功处理了客户端的请求,并且已返回所请求的资源
- 206: 服务器成功处理了部分请求,一般用来做断点续传,或者是视频文件等大文件的加载
- 301: 请求的网页已永久移动到新位置,常用于域名更换
- 302: 临时重定向不会缓存,常用于未登陆的用户访问用户中心重定向到登录页面
- 304: Not Modified. 自从上次请求后,请求的网页未修改过。服务器返回此响应时,不会返回网页内容。
- 400: Bad Request
- 401: 请求要求身份验证
- 403: Forbidden
- 404: 服务器找不到请求的网页
- 405: 禁用请求中指定的方法
- 500: 服务器内部错误
- 501: Not Implemented
- 502: Bad Gateway. 请求未完成,服务器从上游服务器收到一个无效的响应
- 503: Service Unvailable.
- 504: Gateway Timeout.
- 参考
常见的HTTP方法
- get
- 用于请求数据,通常用于从服务器获取资源或信息
- 幂等的,这意味着多次执行相同的 GET 请求,应该产生相同的结果,不会修改服务器上的数据
- 由于数据通过 URL 传递,浏览器和服务器对 URL 长度有一定限制,通常在 2KB 到 8KB 范围内
- put
- delete
- post
- 用于向服务器发送数据,一般用于提交表单、上传文件或触发服务器上的某种动作
- 不是幂等的,每次发送 POST 请求都可能修改服务器上的数据或引发不同的操作
- head
常见的HTTP 请求头
- Host
- User-Agent
- Accept
- Accept-Encoding: zip, deflate, br
- Accept-Language
- Authorization
- Content-Type
- Content-Length : 指示请求体的字节长度
- Referer: 告诉服务器从哪个页面发起的请求
- Connection:
Connection: keep-alive
- Cache-Control
- Origin: 发起请求的来源
- Range: 用于请求资源的部分内容,常见于下载请求中,指定从哪个字节位置开始获取资源
Content-Type
- 用于指示资源的原始媒体类型
- 常见格式
- text/html
- text/plain
- image/png
- application/json
- application/octet-stream
- application/x-www-form-urlencoded
- multipart/form-data
- 参考:
HTTP/1.1、HTTP/2 和 HTTP/3 的介绍及它们的主要区别
- HTTP/1.1
- 特点
持久连接:在 HTTP/1.0 中,每次请求都需要新建一个 TCP 连接,而 HTTP/1.1 引入了持久连接(Keep-Alive),允许多个请求复用同一个连接,从而减少了建立连接的开销。
管线化(Pipelining):HTTP/1.1 支持请求管线化,即可以在发送一个请求后,不等响应完成就发送下一个请求,从而减少等待时间。不过由于实现复杂,这个特性并没有得到广泛应用。
缓存控制:HTTP/1.1 引入了更灵活的缓存机制,通过
Cache-Control
和ETag
头部来优化缓存和验证机制,减少了重复的数据传输。Host 头部:HTTP/1.1 要求所有请求都包含
Host
头部,使得一个服务器可以托管多个域名(虚拟主机)。
- 局限性:
- 队头阻塞(Head-of-Line Blocking):由于 HTTP/1.1 基于单一的 TCP 连接,当一个请求阻塞时,后续的请求也会被阻塞。
- 并发连接的限制:浏览器为了加速页面加载,往往需要建立多个 TCP 连接来并行加载资源,但这会加重服务器和网络的负担。Chrome浏览器通常允许每个域名同时发出的最大连接数为6个。
- HTTP/2
- 特点
二进制协议:HTTP/2 使用二进制格式而不是 HTTP/1.1 的文本格式,这样数据可以更高效地解析和处理。
多路复用(Multiplexing):HTTP/2 允许在同一个 TCP 连接上同时发送多个请求和响应,避免了队头阻塞。每个请求被分为独立的帧,并通过流 ID 来区分,这些帧可以交错传输。
头部压缩:HTTP/2 使用 HPACK 算法对头部信息进行压缩,减少了冗余数据的传输,尤其是当多个请求使用相同的头部时,效果尤为显著。
服务器推送:服务器可以主动向客户端推送可能会用到的资源(例如 CSS 或 JS 文件),即使客户端还没有请求这些资源。这样可以减少等待时间,加快页面加载速度。
- 局限性
虽然多路复用减少了队头阻塞,但 HTTP/2 仍然基于 TCP,TCP 连接的队头阻塞问题没有完全消除。
在网络丢包的情况下,TCP 的重传机制会导致整个连接中的所有数据都受到影响。
HTTP/3
- 特点
基于 QUIC 的传输协议:QUIC 是一种基于 UDP 的传输协议,它通过在用户态实现拥塞控制、重传等功能,减少了握手和延迟。QUIC 的最大特点是可以避免 TCP 的队头阻塞。
更快的握手:QUIC 通过 0-RTT 和 1-RTT 的握手机制,实现了比 TCP 快得多的连接建立时间。传统的 TCP 需要三次握手,而 QUIC 可以在一次往返中建立连接,减少了延迟。
独立的流:QUIC 协议允许在一个连接中传输多个独立的流,即使某个流中有数据丢失,其他流不会受到影响,从而彻底解决了 TCP 的队头阻塞问题。
内置加密:与 HTTP/2 一样,HTTP/3 默认要求加密。QUIC 本身就内置了 TLS 加密功能,简化了加密过程,提高了安全性。
- 特点
使用 UDP 而非 TCP的原因
- UDP 提供了更高的灵活性和效率
- QUIC 协议通过在应用层实现流控、拥塞控制、加密等功能,避免了 TCP 的许多限制,如队头阻塞、慢速连接建立和复杂的中间设备干扰
- QUIC 通过 UDP 实现了更快的连接建立、灵活的连接管理和更强的传输性能
局限性:
- 部署复杂性:由于 HTTP/3 基于 QUIC,而 QUIC 使用 UDP 传输,因此需要服务器和网络设备对 UDP 有良好的支持。这对某些旧的网络基础设施可能带来挑战。
HTTP/1.1、HTTP/2 和 HTTP/3 的对比
特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
---|---|---|---|
协议类型 | 文本协议 | 二进制协议 | 基于 QUIC(UDP) |
连接复用 | 不支持 | 支持多路复用 | 支持多路复用 |
队头阻塞 | 存在(TCP 层) | 存在(TCP 层) | 彻底解决(基于 QUIC) |
头部压缩 | 不支持 | 支持(HPACK) | 支持(QPACK) |
服务器推送 | 不支持 | 支持 | 支持 |
加密 | 可选 | 默认加密(基于 TLS) | 默认加密(基于 QUIC 内置 TLS) |
握手延迟 | 需要三次握手 | 需要三次握手 | 0-RTT 和 1-RTT 握手,延迟更低 |
HTTP 和 HTTPS 区别
HTTPS 是在 HTTP 协议基础上实施 TLS 加密,所有网站以及其他部分 web 服务都使用该协议。因此,任何使用 HTTPS 的网站都使用 TLS 加密。
HTTPS目的
- 数据加密
- 数据一致性
- 身份认证
参考:
HTTPS原理
依靠**TLS(传输层安全性协议)**来提供加密、认证和数据完整性。
加密通信
- HTTPS 使用对称加密和非对称加密结合的方式来加密通信:
- 非对称加密:在连接开始时,客户端和服务器通过非对称加密(公钥和私钥)进行握手。服务器提供一个公钥,客户端使用这个公钥加密信息,然后服务器用自己的私钥解密。由于公钥是公开的,而私钥是保密的,这确保了只有服务器能够解密加密的信息。
- 对称加密:握手过程中,双方会生成一个共享的会话密钥(对称密钥)。这个对称密钥用于接下来的通信,因为对称加密在处理大量数据时比非对称加密快得多。
身份认证
- HTTPS 使用数字证书和**证书颁发机构(CA)**来验证服务器的身份,确保客户端正在与合法的服务器通信,而不是中间人攻击者。
- 数字证书:服务器必须提供一个受信任的数字证书,通常由一个可信的CA(如Let’s Encrypt、DigiCert等)签发。数字证书中包含了服务器的公钥和证书持有者的信息。
- 证书验证:客户端会检查这个证书是否由受信任的CA签发,是否有效,以及是否与服务器的域名匹配。如果证书有问题,浏览器会警告用户。
数据完整性
- HTTPS 通过使用哈希函数(如 SHA256)来确保数据传输的完整性。具体来说,每个数据包都会附带一个哈希值,接收方可以通过这个哈希值验证数据是否在传输过程中被篡改。如果数据被篡改,哈希值将不匹配,通信会被终止。
握手过程(TLS握手)
- 客户端Hello:客户端发送一个请求,包含可支持的加密算法、TLS版本等信息。
- 服务器Hello:服务器响应,并发送数字证书和选择的加密算法。
- 密钥交换:客户端使用服务器的公钥加密生成的会话密钥,并将其发送给服务器。服务器用私钥解密并获得该密钥。
- 握手完成:双方开始使用会话密钥进行对称加密的通信。
HTTPS缺陷(SNI)
- ClientHello 中的 SNI(Server Name Indication)
- GFW 基于 SNI 来掐断你的 HTTPS 握手
- 境内公有云基于 SNI 来阻断未备案的域名
HTTPS 攻击方式
- 中间人攻击(Man-in-the-Middle Attack, MITM)
- 攻击方法
- 恶意Wi-Fi热点:攻击者设置一个假冒的公共Wi-Fi热点,诱使用户连接,通过DNS劫持或使用不安全的HTTP版本,拦截流量。
- 恶意代理:在客户端与服务器之间,攻击者可能通过劫持代理服务器来解密和重新加密数据。
- 防范措施:确保证书和域名验证正确,使用HSTS(HTTP Strict Transport Security)强制HTTPS连接,避免降级到不安全的HTTP。
- SSL剥离攻击(SSL Stripping)
- SSL剥离攻击是中间人攻击的一种特殊形式,攻击者强迫客户端与服务器使用HTTP而不是HTTPS。攻击者拦截客户端请求,并将其重写为HTTP(即明文),然后在服务器和攻击者之间使用HTTPS。
- 攻击方法:用户尝试通过HTTP连接到网站,服务器重定向到HTTPS,但攻击者在重定向之前拦截并降级为HTTP。
- 防范措施:启用HSTS策略,它能确保浏览器在连接时始终使用HTTPS,并阻止降级为HTTP的攻击。
- 证书伪造或冒充攻击
- 证书伪造:攻击者可能通过不安全的证书颁发机构(CA)或通过社会工程手段获得伪造的证书,假冒合法网站。
- 中间证书颁发机构滥用:如果中间证书颁发机构被攻击者控制,他们可能使用合法的中间证书签发虚假的证书。
- 防范措施:启用证书透明度(Certificate Transparency),它可以帮助检测和阻止伪造证书。现代浏览器会警告用户关于无效或伪造的证书。
- 降级攻击(Downgrade Attack)
- 攻击方法: 攻击者强迫客户端和服务器使用较弱的加密算法或不安全的TLS版本(如SSL 3.0或TLS 1.0),以便更容易进行破解或解密。
- 防范措施:服务器应该禁用过时的SSL/TLS版本和弱加密算法(如RC4),并仅支持最新的TLS协议版本。
- TLS重协商攻击
- 攻击方法: TLS的重协商机制可能被攻击者利用,插入自己的数据到加密会话中,欺骗服务器认为这些数据来自合法的客户端。
- 防范措施:确保服务器和客户端都使用安全的TLS重协商机制,并打补丁修复已知漏洞。
- 恶意软件和浏览器劫持
- 攻击方法:即使HTTPS保护了传输中的数据,攻击者仍然可能通过用户设备上的恶意软件或浏览器劫持绕过HTTPS。例如,某些恶意软件可以劫持浏览器流量,将用户重定向到虚假网站,即使启用了HTTPS。
- 防范措施:保持操作系统和软件的安全更新,使用防病毒软件,并提高用户安全意识。
DNS
DNS 查询顺序
- 浏览器 DNS 缓存
- 浏览器调用 getaddrinfo() 查询数据,其中 getaddrinfo() 会根据如下顺序查询
- 先看 /etc/hosts 文件
- 通过主机名服务/mDNS 查询
- 通过 systemd-resolved 查询
- 最后通过 DHCP 下发的 DNS 查询
- 一级级往上查询直到根 DNS 服务器
使用协议
- DNS在进行区域传输的时候使用TCP协议
- 其它时候则使用UDP协议
- 默认端口号: 53
DNS安全
参考
- DNS为什么既使用TCP又使用UDP? | 为什么这么涛的个人博客
- 重新思考浏览器输入了 URL 并按下回车之后到底发生了什么——本地 DNS 部分 | Nova Kwok’s Awesome Blog
SSL / TLS
SSL (Secure Socket Layer)
- 安全套接字层
TLS (Transport Layer Security)
- SSL的升级版
- 作用
- 加密
- 身份验证
- 完整性
参考
- 什么是传输层安全性(TLS)? | Cloudflare
- 深入探究 SSL/TLS 协议 | Liuyib’s Blog
- 网络安全科普:奇妙的 SSL/TLS 证书(基础篇) - Joe’s Blog
- TLS/ESNI/ECH/DoT/DoH/JA3 - 谈谈 HTTPS 网络下浏览体验安全性的最后缝隙 - Joe’s Blog
- 网络安全科普:奇妙的 SSL/TLS 证书(基础篇) - Joe’s Blog
- HTTPS 隐私安全的一些实践
ipv4与ipv6
- ipv6的环回地址: 0:0:0:0:0:0:0:1,通常也简写为::1
- 参考:
CDN
- CDN(Content Delivery Network,内容分发网络)
- CDN通过将内容缓存到全球多个节点(也称为边缘服务器)上,使得用户能够从最近的服务器获取数据,从而加快访问速度并减少延迟。
- Amazon CloudFront 是 Amazon Web Services(AWS)提供的全球内容分发网络(CDN)服务
待分类
网络包
轮询、长轮询(Long polling)、WebSocket
- 轮询:定期向服务器发出请求
- 长轮询过程
- 请求发送到服务器。
- 服务器在有消息之前不会关闭连接。
- 当消息出现时 —— 服务器将对其请求作出响应。
- 浏览器立即发出一个新的请求。
- WebSocket提供了一种在浏览器和服务器之间建立持久连接来交换数据的方法。数据可以作为“数据包”在两个方向上传递,而无需中断连接也无需额外的 HTTP 请求。
- 参考
ARP
ARP(Address Resolution Protocol,地址解析协议)是用来将IP地址解析为MAC地址的协议。 主机或三层网络设备上会维护一张ARP表,用于存储IP地址和MAC地址的映射关系,一般ARP表项包括动态ARP表项和静态ARP表项。