计算机网络
2021-08-19 21:22:49 0 举报AI智能生成
计算机网络
作者其他创作
大纲/内容
应用层
HTTP
HTTP是无状态协议
HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理
为了更快地处理大量事务
Cookies 解决需要保存状态的场景
HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）
HTTP报文
请求报文
报文首部
请求行
请求方法 URI 协议版本
请求首部字段
补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
Authorization
告知服务器，用户代理的认证信息
Host
告知服务器，请求的资源所处的互联网主机名和端口号
HTTP/1.1 规范内是**唯一一个必须被包含在请求内的首部字段**。
首部字段 Host 和**以单台服务器分配多个域名的虚拟主机**的工作机制有很密切的关联
相同的 IP 地址下部署运行着多个域名，那么服务器就会无法理解究竟是哪个域名对应的请求。因此，就需要使用首部字段 Host 来明确指出请求的主机名
条件请求
形如 If-xxx 这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求
If-Match
服务器会比对 If-Match 的字段值和资源的 ETag 值，仅当两者一致时，才会执行请求。反之，则返回状态码 412 Precondition Failed 的响应。
If-None-Match
它和首部字段 If-Match作用相反。用于指定 If-None-Match 字段值的实体标记（ETag）值与请求资源的 ETag 不一致时，它就告知服务器处理该请求。
If-Modified-Since
告知服务器若 If-Modified-Since 字段值早于资源的更新时间，则希望能处理该请求。
而在指定 If-Modified-Since 字段值的日期时间之后，如果请求的资源都没有过更新，则返回状态码 304 Not Modified 的响应。
If-Unmodified-Since
告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。
如果在指定日期时间后发生了更新，则以状态码 412 Precondition Failed 作为响应返回
If-Range
告知服务器若指定的 If-Range 字段值（ETag 值或者时间）和请求资源的 ETag 值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。
通用首部字段
请求报文和响应报文两方都会使用的首部。
实体首部字段
补充了资源内容更新时间等与实体有关的信息。
Allow
首部字段 Allow 用于通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。当服务器接收到不支持的 HTTP 方法时，会以状态码405 Method Not Allowed 作为响应返回。与此同时，还会把所有能支持的 HTTP 方法写入首部字段 Allow 后返回
报文主体
请求参数
响应报文
响应首部
状态行
协议版本 状态码 状态码的原因短语
响应首部字段
补充了响应的附加内容，也会要求客户端附加额外的内容信息。
ETag
首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的 ETag值。
强 ETag 值
强 ETag 值，不论实体发生多么细微的变化都会改变其值。
弱 ETag 值
弱 ETag 值只用于提示资源是否相同。只有资源发生了根本改变，产生差异时才会改变 ETag 值。这时，会在字段值最开始处附加 W/。
Location
使用首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源。
基本上，该字段会配合 3xx ：Redirection 的响应，提供重定向的URI。
通用首部字段
Cache-Control
缓存请求指令
缓存响应指令
Connection
控制不再转发给代理的首部字段
Connection: 不再转发的首部字段名
管理持久连接
Connection 首部字段的值为 Keep-Alive
实体首部字段
报文主体
响应的HTML等内容
HTTP 请求方法
GET ：获取资源
GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容
请求报文的实体体(entity body)为空
POST：传输实体主体
POST 方法用来传输实体的主体
请求报文的实体体通常为表单内容
PUT：传输文件
PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。
HEAD：获得报文首部
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认URI 的有效性及资源更新的日期时间等
DELETE：删除文件
DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源
OPTIONS：询问支持的方法
OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法
TRACE：追踪路径
TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。
CONNECT：要求用隧道协议连接代理
CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。
主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。
GET POST区别
Get：指定资源请求数据，刷新无害，Get请求的数据会附加到URL中，传输数据的大小受到url的限制。
Post：向指定资源提交要被处理的数据。刷新会使数据会被重复提交。post在发送数据前会先将请求头发送给服务器进行确认，然后才真正发送数据。
HTTP状态码
2XX
200 OK
表示从客户端发来的请求在服务器端被正常处理了
204 No Content
服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。
也不允许返回任何实体的主体。比如，当从浏览器发出请求处理后，返回 204 响应，那么浏览器显示的页面不发生更新。
一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
206 Partial Content
该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。
201 – 已创建。
202 – 已接受。
203 – 非权威性信息。
205 – 重置内容。
202 – 已接受。
203 – 非权威性信息。
205 – 重置内容。
3XX
301 Moved Permanently
永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI。
也就是说，如果已经把资源对应的 URI保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存。
也就是说，如果已经把资源对应的 URI保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存。
302 Found
临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。
不是被永久移动，只是临时性质的。换句话说，已移动的资源对应的URI 将来还有可能发生改变。
用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。
303 See Other
该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源。
303 状态码明确表示客户端应当采用 GET 方法获取资源
301、302 标准是禁止将 POST 方法改变成 GET 方法的，但实际使用时大家都会这么做
304 Not Modified
客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。
304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。
附带条件的请求是指采用 GET 方法的请求报文中包含 If-Match，If-None-Match，If-Modified-Since，If-Unmodified-Since If-Range，中任一首部。
307 Temporary Redirect
临时重定向
该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成 GET，但实际使用时大家并不遵守。
307 会遵照浏览器标准，不会从 POST 变成 GET
307 会遵照浏览器标准，不会从 POST 变成 GET
4XX
400 Bad Request
该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。
该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。
403 Forbidden
- 该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，
-
-
404 Not Found
服务器上无法找到请求的资源
HTTP 405 – 资源被禁止
HTTP 406 – 无法接受
HTTP 407 – 要求代理身份验证
HTTP 410 – 永远不可用
HTTP 412 – 先决条件失败
HTTP 414 – 请求 – URI 太长
HTTP 406 – 无法接受
HTTP 407 – 要求代理身份验证
HTTP 410 – 永远不可用
HTTP 412 – 先决条件失败
HTTP 414 – 请求 – URI 太长
5XX
500 Internal Server Error
服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。
503 Service Unavailable
服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。
Error 501 – 未实现
HTTP 502 – 网关错误
504 – 网关超时
505 – HTTP 版本不受支持。
HTTP 502 – 网关错误
504 – 网关超时
505 – HTTP 版本不受支持。
Cookie & Session
Cookie
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。
当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
Session
Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要通过Cookies中携带的SessionID查询客户档案表就可以了
Cookie管理Session
步骤 1： 客户端把用户 ID 和密码等登录信息放入报文的实体部分，通常是以 POST 方法把请求发送给服务器。
步骤 2： 服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证，
然后把用户的认证状态与Session ID 绑定后记录在服务器端。向客户端返回响应时，会在首部字段 Set-Cookie 内写入 SessionID
然后把用户的认证状态与Session ID 绑定后记录在服务器端。向客户端返回响应时，会在首部字段 Set-Cookie 内写入 SessionID
Session ID 应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。
为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie内加上 httponly 属性。
步骤 3： 客户端接收到从服务器端发来的 Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。
密码加盐
alt 其实就是由服务器随机生成的一个字符串，但是要保证长度足够长，并且是真正随机生成的。
然后把它和密码字符串相连接（前后都可以）生成散列值。
当两个用户使用了同一个密码时，由于随机生成的 salt 值不同，对应的散列值也将是不同的。这样一来，很大程度上减少了密码特征，攻击者也就很难利用自己手中的密码特征库进行破解
代理网关隧道
代理
代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
缓存代理
代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。
当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
透明代理
转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。
网关
网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。
网关能使通信线路上的服务器提供非 HTTP 协议服务。
隧道
隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。
隧道的目的是确保客户端能与服务器进行安全的通信。
隧道本身不会去解析 HTTP 请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束
转发与重定向
转发是服务器行为。服务器直接向目标地址访问URL,将相应内容读取之后发给浏览器，用户浏览器地址栏URL不变，转发页面和转发到的页面可以共享request里面的数据。
重定向是利用服务器返回的状态码来实现的，如果服务器返回301或者302，浏览器收到新的消息后自动跳转到新的网址重新请求资源。用户的地址栏url会发生改变，而且不能共享数据。
SQL注入
SQL 注入（SQL Injection）是指针对 Web 应用使用的数据库，通过运行非法的 SQL 而产生的攻击
通过加入-- 或 ' 达到改变SQL逻辑的结果, 导致可以查看隐私数据或者篡改数据库中的数据
syn 洪泛
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。
SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认
由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用半连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。
防御SYN攻击
缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN-Cookie
收到SYN 报文, 不生成半连接, 生成一个cookie, 返回带有这个cookie的 SYNACK报文
再次收到ACK检查cookie, 之前出现过就是一个合法的ACK, 建立连接分配资源
HTTP 首部注入攻击
攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。
设置任何 Cookie 信息
重定向至任意 URL
显示任意的主体（HTTP 响应截断攻击）
HTTP 响应截断攻击
向首部主体内添加内容的攻击称为 HTTP 响应截断攻击（HTTPResponse Splitting Attack）。
HTTPs
什么是HTTPs
HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版
对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;
对网站服务器进行真实身份认证。
HTTPs工作流程
1.Client发起一个HTTPS的请求
2.Server把事先配置好的**公钥证书**（public key certificate）返回给客户端。
3.Client验证公钥证书：
是否在有效期内，
证书的用途是不是匹配Client请求的站点，
有没有被吊销
它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书
4.Client使用**伪随机数生成器**生成加密所使用的**对称密钥**，然后用证书的公钥加密这个对称密钥，发Server。
5.Server使用自己的**私钥**（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了**相同的对称密钥**。
6.Server使用对称密钥加密“明文内容A”，发送给Client。
7.Client使用对称密钥解密响应的密文，得到“明文内容A”。
8. Client Server可以继续使用对称秘钥进行请求与响应
SSL
SSL 握手协议（SSL Handshake Protocol）
它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL 记录协议（SSL Record Protocol）
它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
HTTP存在的问题
通信使用明文（不加密），内容可能被窃听
无法证明报文的完整性，所以可能遭篡改
不验证通信方的身份，因此有可能遭遇伪装
HTTPs的优缺点
HTTPs如何解决HTTP的不安全问题(优势)
对称加密+非对称加密
( **利用非对称加密实现身份认证和密钥协商** ）
内容经过对称加密，每个连接生成一个唯一的加密密钥
解决报文可能遭篡改问题——数字签名
数字签名有两种功效：
能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性,证明数据是否未被篡改过。
生成数字签名
发送文本->hash函数->消息摘要->私钥加密->数字签名
校验数字签名
收到的文本->hash函数->消息摘要
收到的数字签名->公钥解密->解密得到的消息摘要
如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
CA证书
数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。
HTTPs的缺点
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，
（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
中间人攻击
中间人劫持本地请求发送给第三方服务器, 与本地客户端建立了通信, 得知了客户端的请求信息和对称秘钥, 再和服务器进行通信, 使用客户端的请求信息和对称加密秘钥, 再将服务器方的响应通过对称秘钥加密返回给客户端, 在这个过程中, 通信的内容全部被中间人窃取了
- 本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
- 中间人服务器返回中间人自己的证书
- 客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
- 中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
- 中间人以客户端的请求内容再向正规网站发起请求
- 因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据
- 中间人凭借与正规网站建立的对称加密算法对内容进行解密
- 中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输
- 客户端通过与中间人建立的对称加密算法对返回结果数据进行解密
- 中间人服务器返回中间人自己的证书
- 客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
- 中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
- 中间人以客户端的请求内容再向正规网站发起请求
- 因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据
- 中间人凭借与正规网站建立的对称加密算法对内容进行解密
- 中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输
- 客户端通过与中间人建立的对称加密算法对返回结果数据进行解密
由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。
HTTPs被抓包
会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。
浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。
HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情
HTTP vs HTTPs
HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
HTTPS标准端口443，HTTP标准端口80;
HTTP1.0 vs HTTP1.1
缓存处理
HTTP1.0
使用header里的If-Modified-Since,Expires来做为缓存判断的标准，
HTTP1.1
引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
请求资源的部分(range))
HTTP1.0
存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，
HTTP1.1
在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理
HTTP1.0
HTTP1.1
新增了24个错误状态响应码，
Host头处理
HTTP1.0
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。
但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
HTTP1.1
HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
长连接
HTTP1.0
一个TCP连接只能传送一个请求
HTTP1.1
支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理
Pipeling: 若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，
HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
HTTP 1.x vs HTTP 2.0
传输格式
HTTP/1.X
文本格式
HTTP/2
二进制分帧
在二进制分帧层中， HTTP/2 会将所有传输的信息分割为帧（frame）,并对它们采用二进制格式的编码 ，并在每个帧头部记录Stream id 标识所属的的数据流, 接收方根据stream id 将帧归属到不同的请求中
多路复用
HTTP/1.X
一个TCP连接一次只能发送一个请求
HTTP/2
所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。
每个请求是一个数据流，数据流以消息的方式发送，而消息又分为多个帧，帧头部记录着stream id用来标识所属的数据流，不同属的帧可以在连接中随机混杂在一起。接收方可以根据stream id将帧再归属到各自不同的请求当中去。
多路复用（连接共享）可能会导致关键请求被阻塞。HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回给客户端，
header压缩
HTTP/1.X
头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500~800字节的负荷。
HTTP/2
使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，
既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。
既避免了重复header的传输，又减小了需要传输的大小。高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。
服务端推送
HTTP/1.X
HTTP/2
服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。
HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？
HTTP/1.0 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行
会话层
SPDY
其开发目标旨在解决 HTTP 的性能瓶颈，缩短 Web 页面的加载时间
SPDY 以**会话层**的形式加入，控制对数据的流动，但还是采用 HTTP建立通信连接
额外功能
多路复用流
通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高
赋予请求优先级
SPDY 不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
压缩 HTTP 首部
压缩 HTTP 请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
推送功能
支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
服务器提示功能
服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。
传输层
TCP
三次握手
三次握手过程
刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。
此时客户端处于 SYN_SEND 状态。
首部的同步位SYN=1，初始序号seq=x，
SYN=1的报文段不能携带数据，但要消耗掉一个序号。
第二次握手：服务器收到客户端的 SYN 报文，回复SYN ACK报文，指定了服务端初始化序列号 ISN(s)。
服务端指定了自己的初始化序列号 seq=y。
同时会把客户端的 初始序号x + 1 作为确认号 ack 的值，表示自己已经收到了客户端的 SYN，
此时服务器处于 SYN_REVD 的状态。
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
第三次握手：客户端收到 SYN ACK报文之后，会发送一个 ACK 报文，
把服务器的 初始序号y + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，
此时客户端处于 ESTABLISHED 状态。
服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），
ACK报文段可以携带数据，不携带数据则不消耗序号。
三次握手的作用是什么?
- 为了确认双方的接收能力和发送能力是否正常、
- 指定自己的初始化序列号为后面的可靠性传送做准备。
- 实质上其实就是连接服务器指定端口，
- 建立TCP连接，
- 并同步连接双方的序列号和确认号，
- 交换TCP窗口大小信息
- 指定自己的初始化序列号为后面的可靠性传送做准备。
- 实质上其实就是连接服务器指定端口，
- 建立TCP连接，
- 并同步连接双方的序列号和确认号，
- 交换TCP窗口大小信息
为什么三次两次不行吗?
需要三次握手确认服务端和客服端的接受和发送能力正常
第一次握手
客户端发送网络包，服务端收到了
服务端确认：客户端的发送能力、服务端的接收能力是正常的。
第二次握手
服务端发包，客户端收到了。
客户端确认：服务端的接收、发送能力，客户端的接收、发送能力是正常的。
不过此时服务器并不能确认客户端的接收能力和服务端的发送能力是否正常
第三次握手
客户端发包，服务端收到了
服务端确认：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
可能出现的情况
- 如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。
- 客户端收到了第二个连接请求的确认，建立了连接。数据传输完毕后，就释放了连接，
- 客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个报文段延误到连接释放以后的某个时间到达服务端，
- 此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，
- 不采用三次握手，只要服务端发出确认，就建立新的连接了，
- 此时客户端觉得自己没有请求连接忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。
- 客户端收到了第二个连接请求的确认，建立了连接。数据传输完毕后，就释放了连接，
- 客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个报文段延误到连接释放以后的某个时间到达服务端，
- 此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，
- 不采用三次握手，只要服务端发出确认，就建立新的连接了，
- 此时客户端觉得自己没有请求连接忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。
半连接队列
服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
SYN-ACK重传次数
服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。
每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…
如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
ISN(Initial Sequence Number)是固定的吗？
三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据
如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。
三次握手可以携带数据吗
其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据
假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文
对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。
四次挥手
四次握手过程
刚开始双方都处于 ESTABLISHED 状态，
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
报文段 FIN=1 序列号 seq = u
停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态
服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），
服务端进入CLOSE_WAIT（关闭等待）状态
此时的TCP处于半关闭状态，客户端到服务端的连接释放。
客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
服务端没有要向客户端发出的数据
服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），
服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到 FIN 之后，发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），
客户端进入TIME_WAIT（时间等待）状态。
此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
收到一个FIN只意味着在这一方向上没有数据流动
TCP半关闭
TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
为什么需要四次 三次可以吗?
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
释放连接 等待2MSL的意义是什么?
MSL(Maximum Segment Lifetime) 是最长报文段寿命, 它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。 因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。
保证客户端发送的最后一个ACK报文段能够到达服务端。
- 这个ACK报文段有可能丢失，使得处于LAST-ACK状态的服务端收不到对已发送的FIN+ACK报文段的确认，
- 服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，
- 接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，
- 若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
- 服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，
- 接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，
- 若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
防止“已失效的连接请求报文段”出现在本连接中。
- 客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，
- 使下一个新的连接中不会出现这种旧的连接请求报文段。
- 使下一个新的连接中不会出现这种旧的连接请求报文段。
这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。
建立了连接客户端故障怎么办?
TCP还设有一个保活计时器, 服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，
若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，
以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，
以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
流量控制，拥塞控制。滑动窗口。
流量控制 & 滑动窗口
建立连接时，各端分配一个缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端。
接收方发送的确认消息中包含了自己剩余的缓冲区尺寸。剩余缓冲区空间的数量叫做窗口。其实就是建立连接的双方互相知道彼此剩余的缓冲区大小。
拥塞控制
在某段时间，若**对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏**，这种情况就叫做**网络拥塞**。
TCP的四种拥塞控制算法
慢开始：
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。
发送方让自己的发送窗口等于拥塞窗口
由小到大增加拥塞窗口的大小。
先发送一个数据报文段，此后收到几个确认报文段，拥塞窗口的大小就加上对应的数量，
并且第二次发送的报文段数量就等于拥塞窗口的值
并且第二次发送的报文段数量就等于拥塞窗口的值
当前的拥塞窗口cwnd的值已经等于慢开始门限值ssthresh，之后改用拥塞避免算法。
拥塞避免：
每个传输轮次, 拥塞窗口cwnd只能线性加1
发生超时重传, 判断网络可能出现拥塞
将ssthresh更新为发生拥塞时cwnd的一半, 将cwnd的值减少为1, 并重新开始慢开始算法
快重传
发送方收到了累计3个连续的针对某个报文段x的重复确认，立即重传x+1号报文段，而不是等到超时重传计时器超时再重传
这样对于个别丢失的报文段, 发送方不会出现超时重传, 不会误以为出现拥塞, 进而降低拥塞窗口为1 进入慢开始
快恢复
发送方一旦受到3个重复确认, 就知道丢失了个别报文段, 于是不启动慢开始算法而是执行快速恢复算法
发送发将慢开始限制ssthresh 和 拥塞窗口cwnd调整为当前窗口的一半, 执行拥塞避免算法
也有快恢复的实现将cwnd的窗口变成新的ssthresh+3
发送方收到3个重复的确认说明3个数据报文段离开了网络
所以网络中减少了3个报文段而不是堆积了报文段, 因此可以适当增加拥塞窗口
TCP首部
源端口和目标端口
包的序号。主要是为了解决乱序问题
确认序号。发出去的包应该有确认, 这样能知道对方是否收到，如果没收到就应该重新发送，这个解决的是不丢包的问题
状态位
SYN 是发起一个链接，ACK 是回复，RST 是重新连接，FIN 是结束连接。
因为 TCP 是面向连接的，因此需要双方维护连接的状态，这些状态位的包会引起双方的状态变更
因为 TCP 是面向连接的，因此需要双方维护连接的状态，这些状态位的包会引起双方的状态变更
窗口大小，TCP 要做流量控制，需要通信双方各声明一个窗口，标识自己当前的处理能力。
TCP如何实现可靠传输
顺序问题-累计确认
序号
首先为了保证顺序性，每个包都有一个 ID。在建立连接的时候会商定起始 ID 是什么，然后按照 ID 一个个发送
确认号
为了保证不丢包，需要对发送的包都要进行应答, 应答某个之前的 ID，表示这个ID之前的都收到了
丢包问题
超时重传
对每一个发送了但是没有 ACK 的包设定一个定时器，超过了一定的时间就重新发送
快速重传
对于某一个序列号的三次连续确认ACK, 发送方直到这个确认号之后的数据丢失了, 马上重传这一部分数据而不是等到超时重传
流量控制
双方维护一个缓冲区(滑动窗口), 并将缓冲区的大小发送给对方, 保证双方知道彼此剩余的缓冲区大小, 不会发送多余缓冲区大小的数据量
拥塞控制
慢开始
拥塞避免
快重传
快恢复
TCP应用场景
HTTP 浏览器请求响应
FTP 文件传输
POP, SMTP 邮件发送接收
TCP对应的应用层协议
FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上
SMTP：定义了简单邮件传送协议, 用于发送邮件, 服务器开放的是25号端口。
POP3：它是和SMTP对应，POP3用于接收邮件, POP3协议所用的是110端
HTTP：从Web服务器传输超文本到本地浏览器的传送协议。
UDP
UDP特点
不建立连接, 可以同时发送多个数据
不会根据网络情况进行拥塞控制, 流量控制
UDP首部
源端口号和目标端口号
包长度 包括首部和数据的长度之和
校验和
UDP应用场景
对于丢包不敏感的应用，比如 DHCP 就是基于 UDP 协议的。
不需要一对一沟通，建立连接，而是可以广播的应用
需要处理速度快，可以容忍丢包
直播。直播对实时性的要求比较高，宁可丢包，也不要卡顿的，
实时游戏。游戏的特点也是实时性比较高
物联网, 维护TCP代价高, 实时性要求高
UDP对应的应用层协议
DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。
TCP UDP区别
是否面向连接
TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）； UDP提供无连接的传输，通信前不需要建立连接。
传输是否可靠
TCP提供可靠的传输（有序，无差错，不丢失，不重复）； UDP提供不可靠的传输。
传输形式
TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组； UDP是面向数据报的传输，没有分组开销。
是否流量拥塞控制
TCP提供拥塞控制和流量控制机制； UDP不提供拥塞控制和流量控制机制。
socket
四元组
- 客户端ip+port
服务端ip+port
网络层 IP
路由表
记录IP数据在下一跳应该转发给哪个路由器
- 将目标ip地址与路由表中的掩码地址做按位与运算,
- 如果得到的地址和掩码的目标地址相同, 就通过对应的行的gateway发送
- 如果gateway显示的是0.0.0.0 说明在同一个局域网下, 不需要经过中间的路由器直接发出即可
- 如果不是0.0.0.0 就通过对应的网关地址发出 即下一跳地址
转发与路由选择
转发
涉及分组在单一的路由器从一条入链路到一条出链路的传送
路由选择
涉及一个网络的所有路由器, 决定分组从源到目的地所采用而定路径
IP地址
IP地址(网络地址)与物理地址(主机地址)
物理地址是数据链路层和物理层使用的地址，IP地址是网络层和以上各层使用的地址，是一种逻辑地址，其中ARP协议用于IP地址与物理地址的对应。
相同段内相连的主机必须有相同的网络地址,
IP地址的主机标识不允许在同一个网段内重复出现
192.168.144.10/24
网络标识: 192.168.144
标识从数到第几位为止属于网络标识: /24
主机标识: 10
IP地址的分类
A类
IP地址以0开头, 1-8位是网络标识, 后24位是主机标识
0.0.0.0~127.0.0.0 是A类的网络地址
B类
IP地址以10开头, 1-16位是网络标识, 后16位是主机标识
128.0.0.1~191.255.0.0 是B类的网络地址
C类
IP地址以110开头, 1-24位是网络标识, 后8位是主机标识
192.168.0.0~239.255.255.0 是C类的网络地址
D类
IP地址以1110开头, 1-32位是网络标识没有主机标识, 常用于多播
224.0.0.0~239.255.255.255 是A类的网络地址
广播地址
用于在同一个链路中相互连接的主机之间发送数据, IP地址中的主机地址部分全部设置为1就成了广播地址
子网掩码
IP地址的网络标识全部为1, 主机标识全部为0
ping
ICMP 回送消息
向指定的网络地址发送一定长度的数据包，按照约定，若指定网络地址存在的话，会返回同样大小的数据包，当然，若在特定时间内没有返回，就是“超时”，会被认为指定的网络地址不存在。
IPv4 vs IPv6
DNS 解析
DNS（Domain Name System，域名系统）, 通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。
递归解析
局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。
迭代解析
局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止
迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。
ARP 解析
网络层的ARP协议完成了IP地址与物理地址的映射。
每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：
如果有，就直接将数据包发送到这个MAC地址
如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。
此ARP请求数据包里包括源主机的IP地址、MAC地址、以及目的主机的IP地址。
网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。
如果不相同就忽略此数据包；
如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址
源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输
在底层数据链路层, 实时通信需要了解每个IP对应的MAC地址, IP MAC 缺一不可
ARP协议通过IP定位下一个接收数据包的网络设备对应的MAC地址, 如果目标主机不再同一个链路, 通过ARP找到下一条路由器的MAC地址
ICMP
确认IP包是否成功送达目标地址, 通知在发送过程IP包被遗弃的具体原因
ICMP消息
目标消息不可达
IP路由器无法将IP数据包发送给目标地址
重定向消息
路由器发现使用了次优的路径发送数据, 返回重定向消息包含最合适的路由信息
超时消息
TTL(Time To Live) 每经过一次路由器就减少一次, 减到0IP包被丢弃
避免遇到循环, 无休止的在网络上被转发
回送消息(Ping)
用于进行通信的主机之间, 判断发送的数据包是否成功到达对端的消息
可以向对端主机发送回送请求消息(ICMP Echo Request Message, 类型8)
也可以接受对端主机发送回来的回送应答消息(ICMP Echo Reply Message, 类型0)
DHCP
实现自动设置IP地址, 统一管理IP地址分配
NAT
在本地网络使用私有地址, 在连接互联网使用全局IP地址
输入URL到浏览器显示发生了什么?
DNS解析获取域名对应的IP地址
搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询
如果本地DNS服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
对DNS解析得到的IP地址, 浏览器生成HTTP请求报文向web服务器发送HTTP请求
TCP协议完成三次握手建立连接, 将HTTP请求报文分割成报文段, 每个报文段有自己的序号, 可靠的传输给对方
IP协议搜索下一跳路由的地址
ARP协议在路由器将IP地址转换成MAC地址
TCP协议服务器收到报文段根据序列号重组到达的报文段
HTTP协议对请求内容进行处理, 生成响应报文回传客户端
浏览器解析HTML
TCP/IP五层协议模型
应用层(报文(message))
应用进程间的交互来完成特定网络应用
应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则
协议
远程登录
TELNET
TCP
SSH
TCP
文件传输
FTP
TCP
电子邮件
SMTP
TCP
POP
TCP
IMAP
运输层(报文段(segment))
负责向两台主机进程之间的通信提供通用的数据传输服务。
协议
TCP
UDP
网络层(IP数据报(datagram))
分组交换网上的不同主机提供通信服务
地址管理和路由选择
协议
IP
ARP
ICMP
链路层
互连设备之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成**帧**，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）
链路层帧(frame)
IP数据报可能会因为太大而在路由器中被分成更小的IP数据报, 并用链路层帧封装成片
物理层
电信号
URL URI区别
URI
URI，统一资源标志符(Uniform Resource Identifier， URI)，表示的是web上每一种可用的资源，如 HTML文档、图像、视频片段、程序等都由一个URI进行标识的
URL
URL是URI的一个子集。它是Uniform Resource Locator的缩写，译为“统一资源定位 符”。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL是URI概念的一种实现方式。
从上面的例子来看，你可能觉得URI和URL可能是相同的概念，其实并不是，URI和URL都定义了资源是什么，但URL还定义了该如何访问资源。URL是一种具体的URI，它是URI的一个子集，它不仅唯一标识资源，而且还提供了定位该资源的信息。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。
0 条评论
下一页
