IP地址

简介

IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。

组成

每一类地址都由两个固定长度的字段组成，其中一个字段是网络号net-id，它标志主机（或路由器）所连接到的网络，而另一个字段则是主机号host-id，它标志该主机（或路由器）。

image-20201206132449004

image-20201206132458995

各类 IP 地址的网络号字段和主机号字段

image-20201206132538023

各类网络号范围

  • A类0.0.0.0到127.255.255.255
  • B类128.0.0.0到191.255.255.255
  • C类192.0.0.0到223.255.255.255
  • D类224.0.0.0到239.255.255.255
  • E类240.0.0.0到247.255.255.255

注：IP地址的host-id全为0表示网络地址，全为1表示广播地址。

IPv4/IPv6

IPv4占32位（4字节）。

IPv6占128位（16字节）。

子网划分

链接

子网掩码详解

HTTP

HTTP各版本区别

HTTP1.0

  1. 缓存处理：使用header里的If-Modified-Since,Expires（本地时间不准确时不可靠）作为缓存判断标准。
  2. 短连接：每次请求都需要三次握手和四次挥手。TCP连接无法复用。

HTTP1.1

  1. 缓存处理：新增Entity tag，If-Unmodified-Since, If-Match,If-None-Match，cache-control等更多头部字段。
  2. Host头域：在1.0中认为每台服务器绑定唯一一个IP，因此没有传递主机名。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多台虚拟主机，多个虚拟主机共享一个IP。在HTTP1.1中所有请求和响应消息都应该带有Host头域，否则报400错误。
  3. 范围请求（range）：请求头部引入range头域，允许只请求资源的一部分响应码是206。节约了网络带宽资源。
  4. 错误状态码：新增24个错误状态码，如409（Conflict）表示请求资源与资源的当前状态发送冲突；410（Gone）表示服务器上某个资源被永久删除。
  5. 长连接：默认开启Connection：keep-alive，允许一个TCP连接上可以传递多个HTTP请求和响应。降低建立和关闭TCP连接的消耗和延迟。（注： 浏览器最多为每一个域名维护了6个TCP连接）。

HTTP2.0

  1. 多路复用：多个请求复用一条TCP连接，解决了HOL（下面有介绍）问题，降低了延迟同时提高了带宽的利用率。

  2. 请求优先级：可以为请求设置优先级，解决某些关键资源请求被阻塞问题（ 共享TCP连接引发的TCP队头阻塞问题）。

  3. 头部压缩： 通讯双方各自缓存一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

  4. 服务端推送：例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。

  5. 数据格式：HTTP2.0采用二进制格式传输。

HTTP1.0/1.1/2.0区别

注：

HTTP/1.1协议的长连接有两种工作方式，即非流水线方式(without pipelining)和流水线方式(with pipelining)。

  • 非流水线方式在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接要用去两倍RTT的开销，节省了建立TCP连接所需的一个RTT时间。但非流水线方式还是有缺点的，因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。
  • 流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档效率。

HTTP / 1.1流水线 和 HTTP / 2多路复用区别

HTTP / 1.1流水线操作仍然要求按请求的顺序完整地返回请求。

HTTP / 2允许将请求响应拆分为块并以混合的方式返回，从而避免行头阻塞（Head of line【HOL】通常是指每个浏览器/客户端与服务器的连接数量有限，并且对其中一个连接进行新请求必须先等待这些连接完成，然后才能完成行首请求阻止后续请求。HTTP / 2通过引入多路复用来解决此问题，以便发出新的请求）。

TCP队头阻塞行 HTTP / 2仍然受到影响来自另一种HOL，即TCP级别。 TCP流中一个丢失的数据包使，使窗口停止，流一直等待，直到重新发送和接收该包为止。HTTP / 3正在通过QUIC协议（UDP实现）来解决该HOL问题。

详细知识链接

基础知识

HTTP头部

HTTP和HTTPS协议

HTTPS连接过程

http的三次握手与四次挥手

MSL（Maximum Segment Lifetime报文最大生存时间）

从输入URL到页面加载发生了什么

HTTP长连接与短连接，实质上是TCP的长连接

Http缓存原理

Cache-Control

QUIC（Quick UDP Internet Connection）

DNS

DNS（Domain Name System，域名系统），是一项用于管理和解析域名与 IP 地址对应关系的技术，能够将域名或 IP 地址，自动查找与之匹配，即将域名解析为 IP地址（正向解析），或将 IP 地址解析为域名（反向解析）。

DNS服务器类型

  • 主服务器：在特定区域内具有唯一性，负责维护该区域内的域名与 IP 地址之间的对应关系。
  • 从服务器：从主服务器中获得域名与 IP 地址的对应关系并进行维护，以防主服务器宕机等情况。
  • 缓存服务器：通过向其他域名解析服务器查询获得域名与 IP 地址的对应关系，并将经常查询的域名信息保存到服务器本地，以此来提高重复查询时的效率。

解析结构

image-20211125154045528

域名查找过程

image-20211125153556332

参考链接

TCP

三次握手，四次挥手

image-20210507155107561

image-20210507155204022

参考链接

TCP三次握手详解

TCP详解

TCP十连问

拥塞控制

拥塞控制算法从BIC到CUBIC

BBR算法与Reno/CUBIC的对比

linux内核bic和cubic实现

快重传

BBR

TCP各状态接收报文情况

TCP交互详解

ICMP

TCP的keep-alive

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
sysctl -a | grep keepalive

// 每隔 7200 s 检测一次
net.ipv4.tcp_keepalive_time = 7200
// 一次最多重传 9 个包，也就是总共发送10次没响应就断开连接
net.ipv4.tcp_keepalive_probes = 9
// 每个包的间隔重传间隔 75 s
net.ipv4.tcp_keepalive_intvl = 75

#也可直接在Linux的/proc/sys/net/ipv4/目录下查看
[root ipv4]#  cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
[root ipv4]# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
[root ipv4]#  cat /proc/sys/net/ipv4/tcp_keepalive_intvl 
75

详细链接

TCP Reset报文使用场景

  1. 客户端尝试给未提供服务的端口建立TCP连接，服务端会回应reset报文
  2. 服务端接收到报文后，发现该TCP报文不在已建立的TCP连接列表中（当前主机已重启）， 则直接向客户端发送Reset报文。
  3. 在通讯过程中一方突然发送异常（如：程序崩溃），这一方会给对方发送Reset报文使其释放连接。
  4. 超时重传超过阈值后，会主动发送Reset报文释放连接（如：服务端TCP三次握手一直未收到确认，重传二次握手）。
  5. 有些应用利用Reset 报文以达速释放TCP连接的，提高TCP释放效率。

一个端口可以建立多个TCP连接

参考链接

参考链接

参考链接

TLS

简介

SSL（Secure Sockets Layer，安全套接字层）协议最初是网景公司为了保障网上交易安全而开发的，该协议通过加密来保护客户个人资料，通过认证和完整性检查来确保交易安全。IETF 后来在标准化 SSL 协议时，将其改名为 Transport Layer Security（TLS，传输层安全）。

image-20220220143039426

TLS握手

image-20220220143003913

TLS首次连接需要6次握手：假设“光通过光纤”的单程时间都是 28 ms，6次握手如下。

  1. 0 ms：TLS 在可靠的传输层（TCP）之上运行，这意味着首先必须完成 TCP 的“三次握手”，即一次完整的往返。
  2. 56 ms：TCP 连接建立之后，客户端再以纯文本形式发送一些规格说明，比如它所运 行的 TLS 协议的版本、它所支持的加密套件列表，以及它支持或希望使用的另外一些 TLS 选项。
  3. 84 ms：然后，服务器取得 TLS 协议版本以备将来通信使用，从客户端提供的加密套件列表中选择一个，再附上自己的证书，将响应发送回客户端。作为可选项，服务器也可以发送一个请求，要求客户端提供证书以及其他 TLS 扩展参数。
  4. 112 ms：假设两端经过协商确定了共同的版本和加密套件，客户端也高高兴兴地 把自己的证书提供给了服务器。然后，客户端会生成一个新的对称密钥，用服务器的公钥来加密，加密后发送给服务器，告诉服务器可以开始加密通信了。到目前为止，除了用服务器公钥加密的新对称密钥之外，所有数据都以明文形式发送。
  5. 140 ms：最后，服务器解密出客户端发来的对称密钥，通过验证消息的 MAC 检测消息完整性，再返回给客户端一个加密的“Finished”消息。
  6. 168 ms：客户端用它之前生成的对称密钥解密这条消息，验证 MAC，如果一切顺利，则建立信道并开始发送应用数据。

会话回复

完整 TLS 握手会带来额外的延迟和计算量，从而给所有依赖安全通信的应用造成严重的性能损失。为了挽回某些损失，TLS 提供了恢复功能，即在多个连接间共享协商后的安全密钥。

会话标识符（会话缓存）

最早的“会话标识符”（Session Identifier，RFC 5246）机制是在 SSL 2.0 中引入的，支持服务器创建 32 字节的会话标识符。服务器会为每个客户端保存一个会话 ID 和协商后的会话参数。客户端保存会话 ID 信息，并将该 ID 包含在后续会话的“ClientHello”消息中，从而告诉服务器自己还记着上次握手协商后的加密套件和密钥呢，这些都可以重用。假设客户端和服务器都可以在自己的缓存中找到共享的会话 ID 参数，那么就可以进行简短握手。

image-20220220145837411

优点

借助会话标识符可以节省一次往返，还可以省掉用于协商共享加密密钥的公钥加密计算。由于重用了之前协商过的会话数据，就可以迅速建立一个加密连接，而且同样安全。

缺点

服务器必须为每个客户端都创建和维护一段会话缓存。由于每个打开的 TLS 连接都要占用内存，因此需要一套会话 ID 缓存和清除策略，对于拥有很多服务器而且为获得最佳性能必须使用共享TLS 会话缓存的热门站点而言，部署这些策略绝非易事。

会话记录单（无状态回复）

服务器可以在完整 TLS 握手的最后一次交换中添加一条“新会话记录单”（New Session Ticket）记录，包含只有服务器知道的安全密钥加密过的所有会话数据。客户端将这个会话记录单保存起来，在后续会话的 ClientHello 消息中，可以将其包含在 SessionTicket 扩展中。所有会话数据只保存在客户端，而由于数据被加密过，且密钥只有服务器知道，因此仍然是安全的。

优点

无状态恢复机制的优点主要是消除了服务器端的缓存负担，通过要求客户端在与服务器建立新连接时提供会话记录单简化了部署。

缺点

服务器需要解密会话数据，占用CPU资源。

参考

《Web性能权威指南》

网络协议、socket、webSocket

webSocket原理

webSocket数据帧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

详情

报文结构

TCP报文

TCP报文

UDP报文

UDP报文

IP报文

IP报文

HTTP请求报文

HTTP报文

各层网络协议

其他扩展知识

打洞

打洞原理及应用

NAT穿透，UDP打洞