计网常识
计网常识
[toc]
五层协议
物理层
解决在各种传输媒体上传输比特0 和 1 的问题，给数据链路层提供透明传输比特流的服务
透明： 数据链路层不需要知道物理层使用什么方法传输的
数据链路层
三个重要问题： 封装成帧、差错检测、可靠传输
链路：一个节点到相邻节点的一段物理线路，中间没有任何其他的交换节点
数据链路：实现通信协议的硬件和软件加到连路上，以帧单位封装处理
帧传输过程中出现误码（1变成0）
发送方发送数据前将发送的数据和算法计算出检错码，放在帧尾
接受方再进行验证，如果错误，则不会接受该帧，就丢弃了
封装成帧
给上层交付的协议数据单元添加帧头和帧尾使之成为帧
帧头帧尾：进行帧定界 ---
- 帧定界标志（不一定有）
- 物理层添加前导码，帧间隔时间 96bit
透明传输：数据链路层对上层交付的传输数据没有任何限制，就好像数据链路层不存在一样
- 面向字节的物理链路使用字节填充的方法实现透明传输 -- ESC 27
- 面向比特的物理链路使用比特填充的方法实现透明传输
如何解决不同方式的误判（与界定符相同）
差错检测
比特差错：比特传输时1 0 可能会改变
误码率：错误的比特占比
判断：差错检测码
奇偶校验： 在数据后添加1 是的整个数据 的1 的个数为奇数(奇校验)或者偶数(偶校验)
缺点，只能检测奇数位的错误
循环冗余校验：双方约定好一个生成多项式（多项式的各项系数生成比特串），发送方基于待发送的数据和生成多项式计算出差错检测码，也就是冗余码，添加到带传输的后面一起传输（类似Digest的数字签名），接收方通过此方法判断
image-20210331221431870
可靠传输
向上层的服务类型：
不可靠传输服务：丢弃有误码的帧，然后什么都不做
可靠传输服务：发送端发什么就接受什
一般交由上层处理
点对点协议
PPP Point to Point Protocol
为在点对点链路传输各种协议数据报提供了标准方法
从ISP 互联网服务提供商 中国移动..... 获得提供的合法ip地址
存在误判 ，解决方法
帧定界
image-20210401103442613 前导码
地址
Mac地址
点对点信道的数据链路层不需要地址
使用广播信道的数据链路层需要使用地址来区分
单播 发送Mac地址不匹配，丢弃
广播帧 目的字段 FFFFFFFFFFFF 接受
多播 多播地址 多播组列表
IP地址
网际层
因特网上主机和路由器使用的地址
网络编号 和 主机编号
同一网络的网络编号是相同的
网络传播需要IP地址和Mac地址
网络传输中主机有运输层和应用层... 而路由器的最高层就是网络层
封装时的地址
ARP
IP地址转MAC地址
地址解析协议
每个主机都有 ARP高速缓存表 ---- 电话簿
ARP请求报文发送在MAC帧中 只能在一个网络 一个链路中使用
网络层
主要任务：实现网络互连，实现数据包在网络间的传输
解决问题：网络层寻址问题 提供怎样的服务 路由选择问题（不同路径选择）
**网络层提供的两种服务 **
面向连接的虚电路服务：
无连接的数据报服务
TCP/IP体系结构的因特网网际层采用
image-20210401225008037
IPV4
因特网每一台主机/路由器 的每一个接口分配在全世界唯一的32比特标识符
分类编制
A类地址
B类地址
C类地址
特殊情况
划分子网
需要划分子网，利用原有网络中大量剩余的IP地址，分配第三部分...
因此有了：子网掩码
32比特的子网掩码可以表明分类IP地址的主机号部分被借用了几个比特作为子网号
注意不同的网络类别有不同位数的网络号和主机号
举个例子
如何被划分成两个子网的
默认子网掩码
A类 8位网络号 ： 255.0.0.0
B类 16位网络号 255.255.0.0
C类 24位网络号 255.255.255.0
注意，主机号为0代表有一个 为1000000 代表有两个 （注意方向和顺序）
无分类编址
数量巨大的C雷王因为地址空间太小并没有充分使用，而IP地址仍在加速消耗，IPV4地址空间紧张
CIDR Classless Inter Domain Routing
消除了传统的A\B\C类地址和划分子网的概念，更有效的分配Ipv4地址空间，并且可以在新的Ipv6使用之前允许因特网的规模继续增长
斜线记法
128.14.35.7 / 20 代表网络前缀占用的比特数量为20 主机编号就为12
路由聚合 （构造超网）
方法： 找共同前缀
IPV4的地址应用规划
定长： 先确定主机数
变长的子网掩码相当于串行动态分配
Http
HyperTextTransferProtocol 超文本传输协议 用于从WWW服务器传输超文本到本地浏览器的传输协议
所有消息用明文发送 通过公共的互联网
HTTP报文字段梳理[HTTP报文首部]https://www.processon.com/view/link/58025201e4b0d6b27dd4c8af#map
请求方法
| 方法 | 版本 | 描述 |
|---|---|---|
| GET | HTTP1.0 | 请求指定的页面信息，返回实体主体 |
| HEAD | HTTP1.0 | 类似GET请求，但返回的响应中没有具体的内容，用于获取报头 |
| POST | HTTP1.0 | 向指定资源提交数据进行处理请求(提交表单或者上传文件), 数据被包含在请求体中。POST请求可能导致新的资源的建立或者已有资源更新 |
| PUT | HTTP1.1 | 用请求有效载荷替换目标资源的所有当前表示。 |
| DELETE | HTTP1.1 | 删除指定的资源 |
| CONNECT | HTTP1.1 | 建立一个到由目标资源标识的服务器的隧道(连接到能将连接改为管道方式的代理服务器) |
| OPTIONS | HTTP1.1 | 描述目标资源的通信选项 |
| TRACE | HTTP1.1 | 沿着目标资源的路径执行一个消息环回测试(回显服务器收到的请求) |
| PATCH | HTTP1.1 | 对资源应用部分进行修改(只改一部分属性) |
区别POST和PUT方法的差异
关键在于PUT方法是幂等的,第一次调用和多次调用PUT请求产生始终相同的副作用(要么创建要么更新)，且要求前端提供的是一个完整的资源对象(也就是必须已知对象类型); 而多次调用POST请求则可能会创建多个相同资源(POST方法主要是新建资源) (POST不要求已知对象类型, 一般知识修改目标对象的部分内容)(GET/PUT/DELETE方法都是幂等的)
常见的网络请求码
- 101 等到接受其他部分
- 200 处理成功
- 201 请求成功服务器创建了新的资源
- 202 服务器接受请求但未处理
- 204 无内容
- 301 永久移动
- 302 临时移动
- 304 缓存没过期，可以直接用缓存
- 400 错误请求 语法
- 401 未身份认证 需要登陆
- 403 未授权(权限不够) 服务器拒绝请求
- 404 找不到请求资源路径
- 405 禁止请求中指定的方法
- 408 请求超时
- 500 服务器内部错误
- 502 网关/代理错误
- 503 服务不可用
- 505 http版本不支持
HTTP1.0
- 每次请求都需要TCP握手
- 存在队头阻塞
HTTP1.1
- 采用长连接，每次请求用以前的连接即可
- 新增五个请求方法
- 目前一般使用HTTP1.1
- 解决对同一域名请求次数过多(浏览器会限制一段时间内对同一域名到请求数)：
- 管线技术: 一个连接可以一次发多个请求但响应必须要按顺序接收 (不太常用)
- 精灵图：多个元素小图整合到一张大图发给客户端然后再裁剪
- Data URL: 经过Base64编码以字符串方式表示
- 域名分片: 同时请求多个域名
Http2.0
多路复用
多路复用技术：解决HTTP1.1队头阻塞的问题 单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大；由于减少TCP 慢启动时间，提高传输的速度. 允许单一HTTP 2 连接同时发起多重的请求 - 响应消息
多个Stream复用一条TCP连接达到并发效果
- 一个TCP连接包含多个Stream，Stream中包含多个Message,
- Message对应HTTP1.x的一个请求或响应。Message包含多个Frame
- Frame是HTTP2的最小单位，以二进制压缩格式放在HTTP1.x的内容， 一条HTTP消息可由多个Frame组成(合称为一条Message)。一条Frame可以由多个TCP报文组成
在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。
二进制分帧
在二进制分帧层中， HTTP/2 会将所有传输的信息分割为帧（frame）,并对它们采用二进制格式的编码 ，其中 首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。这也就类似TCP数据包的结构了，每个HTTP2包具有标识该Stream的ID，标识该 Frame 属于哪个 Stream.所以即使请求是不按序的，也可以根据相同ID的流来进行顺序组合
HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
首部压缩
HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。
随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。
我们再用通俗的语言解释下，压缩的原理。头部压缩需要在支持 HTTP/2 的浏览器和服务端之间：
- 维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合(61种)；
- 维护一份相同的动态字典（Dynamic Table），可以动态的添加内容。使得动态表生效有一个前提：必须同一个连接上，重复传输完全相同的 HTTP 头部
- 支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding） (包含ASCII码表)；
静态字典的作用有两个：
1）对于完全匹配的头部键值对，例如 “:method :GET”，可以直接使用一个字符表示；
2）对于头部名称可以匹配的键值对，例如 “cookie :xxxxxxx”，可以将名称使用一个字符表示。
HTTP/2 中的静态字典如下（以下只截取了部分）：
浏览器和服务端都可以向动态字典中添加键值对，之后这个键值对就可以使用一个字符表示了。需要注意的是，动态字典上下文有关，需要为每个 HTTP/2 连接维护不同的字典。在传输过程中使用，使用字符代替键值对大大减少传输的数据量。
服务器推送
服务端推送是一种在客户端请求之前发送数据的机制。当代网页使用了许多资源:HTML、样式表、脚本、图片等等。在HTTP/1.x中这些资源每一个都必须明确地请求。这可能是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。
为了改善延迟，HTTP/2引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前。一个服务器经常知道一个页面需要很多附加资源，在它响应浏览器第一个请求的时候，可以开始推送这些资源。这允许服务端去完全充分地利用一个可能空闲的网络，改善页面加载时间。
需要注意的是，这和WebSocket的全双工协议是不同的，HTTP2的推送还属于是被动推送(资源文件)。
HTTP3.0
基于TCP而存在的问题
HTTP2还是存在队头阻塞(在TCP层面，数据包丢失会重传)
因为HTTP/2仍然基于TCP传输数据，TCP层必须保证收到的字节数据是完整且连续的，当前一个包数据没有到达后或丢包后，后续的包数据智能放在内核缓冲区中，该TCP连接中的所有请求都会被阻塞。只有等到该包数据到达时，HTTP/2应用层才能从内核中拿到数据。例如Stream 2 有个TCP包丢失，那么Stream 3 Stream 4都会被阻塞，所以要摆脱传统TCP
并且TLS和TCP握手时存在3个RTT，且由于TCP拥塞控制的慢启动过程，刚开始的TCP连接很慢。
并且当网络场景切换时，例如WiFi变成4G或重新更换WiFi节点，都会引发TLS与TCP重新连接。所以
将TCP和TLS握手过程整合。在UDP基础上建立了新的应用层协议 QUIC，数据帧移动到QUIC里，在传输层就有了数据帧。QUIC帧->QUIC数据包，又会加上Connection
ID区分连接
无队头阻塞
UDP不会保证数据包可靠性，由QUIC协议保证数据包可靠性，每个QUIC数据包都有唯一序号表示，如果流的一个数据包丢失了，即使该流的其他数据包到达，也无法被HTTP3读取，直到QUIC重传丢失的报文。而不会影响其他流。(分Stream ID以及Unique ID)
更快连接
合并TLS
基于HTTP的TCP和TLS是分层的，一个是内核实现的传输层，一个是OpenSSL实现的表示层，所以要分批。
而HTP3在传输数据前需要QUIC协议握手来确认连接ID(UDP没有握手环节), 整个过程只需要1RTT。这是因为QUIC内部包含TLS，会在自己的帧内携带TLS的记录(并且使用TLS1.3)，因此1个RTT可同时完成建立连接和密钥连接
连接迁移
并且HTTP3没有基于TCP四元组来确定连接的，而是使用连接ID来标记两个通信端点，所以网络变化后，只要保持上下文信息(TLS密钥、连接ID)，就可以复用原连接。
Https
两大法宝
SSL Secure Sockets Layer 安全套接层 使用公匙加密 SSL证书
TLS Transport Layer Security 传输层安全 最新行业标准加密协议 继承SSL
数字证书
解决问题：身份伪装(有第三者拦截了请求方发的请求并装作是接收人)
- 服务器向大家都信任的第三方申请身份证书。
- 客户和服务器建立连接时会先向服务器请求证书
- 服务器发送数字证书给客户端
- 客户端获得服务器证书后，与可信任的第三方进行验证，验证后开始进行正常的内容通信
数字签名
解决问题：数据篡改(第三方把发送方的数据包截取下来，修改关键部分并发给接收方)
验证什么？
- 验证数据是否为目的对象发来的
- 验证数据完整性，即数据是否被篡改
怎么签名？
- 发送方对需要发送的数据进行哈希,数据还是在那里,接收方接收到数据后，按照约定的哈希算法把接收到的数据进行哈希得到哈希值(称为Digest摘要)，然后进行对比
- 对摘要信息进行加密(使用公/私钥进行加密)，生成数字签名Signature，数字签名随数据一起发送给接收方
- 接收方接收到数据包，提取出数字签名，用对应的私/公钥进行解密，解密出的是数据的hash值，再对数据包的数据部分进行哈希运算，将得到的值与解密的值进行对比即可
通信流程
TLS 1.2版本。注意⚠️ ，在这以前已经进行了TCP三次握手
- “Client Hello” 客户端向服务端发起建立HTTPS请求 (端口443)(客户端随机数R1、客户端支持的加密套件、TLS版本)
- “Server Hello” 服务端确认支持的TLS版本并从客户端支持的加密套件中选一个作为会话秘钥算法，并生成随机数R2
- “Certificate” 服务器再发一个请求，向客户端发送数字证书
- “Server Key Exchange” 服务器发送自己的公钥
- “Server Hello Done” 服务器说自己发完了
- “Client Key Exchange”客户端验证数字证书(用CA的公钥解密被CA私钥加密的证书并且使用指定的信息摘要算法)，通过验证后客户端生成随机数R3(预主密钥 )，客户端用刚收到的公钥加密预主密钥R3并发给服务端，然后用R1 R2和预主密钥R3运算得到会话密钥Key；“Change Cipher Spec”: 以后就用商议好的算法和密钥加密;“Encrypted Handshake Message”: 客户端握手这边流程没什么问题了,可以开始加密了
- “Encrypted Handshake Message” 服务器用私钥解密出预主密钥，然后用随机数R1 R2和预主密钥计算出最终的**会话密钥Key。**然后也说我这边流程没什么问题了，可以加密了。注意这一步，除了服务器私钥被泄漏，除非没人知道预主密钥是什么(除了客户端和服务端),因为用公钥加密必须用私钥解密，而不能用公钥同时加解密，所以这也是这里使用非对称加密算法的精髓所在！
- 开始进行加密通话(核心就是用会会话密钥进行加解密)，此时双方都用对称加密的方式进行加密(不再是公钥私钥，而是一个共同的会话秘钥Key)。由于现在只有通信双方知道会话密钥，且非对称加密方式开销太大(以上步骤已经表明),所以后续数据加密就使用对称加密的方式
需要注意的点：
- 握手期间使用的密钥交换算法(非对称)：RSA等
- 信息摘要算法(哈希): MD5/SHA-256/SHA-1等
- 握手完成后进行加密算法(对称加密): AES/3DES
TCP协议
Transmission Control Protocol 传输控制协议
属于哪一层 运输层 网际层都使用IP协议
面向连接 通信前要建立TCP逻辑连接 --- 三次握手、面向字节流、首部开销大 min20字节 max60字节
可靠传输：重传机制（下文有讲）、流量控制、拥塞控制
报文信息
可靠传输
以字节为单位的滑动窗口 --- 接受窗口和发送窗口
已收到ack确定的报文可以delete
未按序到达的数据包一般临时存放在接受窗口中，等到缺少的字节收到后再按序交付上层应用
累计确认！
超时重传时间选择
RTT： 报文段往返时间（每次可能不同）
RTO: 超时重传时间
如何合理设置RTO时间
报文段丢失重发的情况 误判
传报文段超时情况
针对以上两种情况的新算法：
流量控制
发送方的数据发的太快以至于接收方接受不下，会造成数据的丢失 （2MSL ）
基于滑动窗口机制
接受窗口 rwnd
解决死锁： 持续计时器
接收方收到0窗口通知时，开启计时器，超时则发送零窗口的探测报文(携带1字节数据)，如果对方发来的报文创口也是零，则重置计时器继续等待，如果不是零则打破僵局
既然服务器的窗口为0，那为什么还能接受发送方发来的探测报文段？
规定接受 0窗口探测报文段、确认报文段、携带紧急数据的报文段
三次握手
为什么不用两次握手
- 避免历史连接，防止旧的连接初始化了连接而造成混乱(Seq Num混乱) (最主要原因)
- 同步双方初始化序列号，确保可靠传输
- 避免资源浪费。客户端没有收到ACK报文，会重新发送SYN，服务端每收到一个SYN就会主动建立一个连接。
如果第三次握手发来的ACK包丢失掉，会出现什么
此后服务端仍然处于SYN-RCVD状态等待接受该ACK包，客户端却开始发送数据了。服务端能正常接受吗？两种方案
- 多数情况，客户端进入ESTABLISHED状态会立即发送数据，发送第一个数据包时会携带ACK确认序号，服务端在收到这个数据包时，通过包内的ACK确认号正常进入ESTABLISHED状态
- 如果客户端暂时不发数据，则服务端超时后发送SYN-ACK重传报文
四次挥手
为什么一定要四次挥？
- 关闭连接时，客户端发送ACK-FIN表示我不再发送了，但你还可以继续发完
- 服务端说我收到了，等我把我发的发完我也不会继续等你了
- 服务端继续发送要发的数据，发完后服务端给客户端发送ACK-FIN表示我把我想发的也发完了
- 客户端收到该FIN，给服务端说OK，那我们就关闭连接吧
- 客户端等待2MSL
为什么这里Server的FIN 和 ACK分两次发送呢？因为我们可以得知Client要关闭时，再发送最后一点数据给Client
第二次挥手包丢失，重传的是FIN报文还是ACK报文？ 客户端重发FIN，因为ACK报文是不会被重传的
为什么要有最后一次的挥手？ 如果没有这次挥手，则服务端给客户端发送的FIN报文就不一定能接收到，客户端就认为服务端可能还会有数据要发从而保持连接。
为什么会有2MSL？他有什么作用
- 保证双方正常关闭连接
- 防止历史连接延迟的包被新连接所接受
MSL： Maximum Segment Lifetime 最大报文生存时间，任何报文在网络上存在的最长时间
- 如果客户端不等待，第四次挥手后直接关闭自己连接，此时对服务端而言，如果客户端发来的ACK包丢失，则它不知道客户端是否正常收到第三次挥手时服务端发来的FIN-ACK包，所以就不确定客户端是否已经关闭。
- 如果客户端等待2MSL，(服务端在发送第三次挥手时也会开启计时)，如果第四次挥手ACK丢失后，服务端没接收到，会认为客户端没有接收到自己发来的FIN-ACK报文，则会重传FIN-ACK报文，客户端收到该报文后则会重置2MSL计时器，并发送第四次挥手的ACK报文。如果发送完该报文后且2MSL后客户端没接收到服务端重发的FIN-ACK报文，说明服务端已经接收到最后一次ACK包，客户端知晓服务端已经关闭，所以此时客户端可以关闭
- 另外也能避免第二次挥手后服务端继续发来的数据延迟到达而造成数据混乱情况(如果客户端不等待2MSL，直接断开连接，则如果断开连接后又与相同服务端建立连接，在发新数据的时候，上一次旧连接中第二次挥手后服务端发的数据包延迟到达，且序号刚好符合窗口要求，这时候则会被客户端直接接受，而不会被丢弃，从而造成混乱)
UDP
User Datagram Protocol
无连接，可随时发送数据、网络开销小 速度快 、支持一对一 一对多(广播、多播(指定)) 多对一、报文直接打包、首部开销小 8 字节
面向报文，直接加个报文头就发出去了
DNS
Domain Name ( to ip )System 解析域名 电话簿
过程：
浏览器缓存
系统缓存
ISP、 因特网服务商
根域名服务器 全世界13组 ，可能这个根域名服务器不知道他的ip，但是可以知道谁可以
.com 顶级域名服务器 TLD(.com .net ...)
TLD也不知道时，给权限名称服务器 啥都知道
回传时，进行保存
网络拥塞
拥塞： 网络中某一资源的需求 超过了该资源所能提供的可用部分，网络性能将会变差，出现拥塞而不控制，则网络的吞吐量就会随着负荷的增大而下降（堵车）
cnwd、ssthresh、rtt、swnd、数据包文段、重传计时器
TCP Tahoe
慢开始 cnwd >> 1
拥塞避免 cnwd++
TCP Reno 改进后
原因： 有时 个别报文段在网络中丢失，但实际上网络并未发生拥塞，这将导致发送方超时重传，并误认为网络发生拥塞。发送方错误地启动慢开始算法，降低了传输效率
快重传 让发送方尽快知道发生了个别报文段的丢失 ，而不是让超市重传计时器超时后再重传 相等的ack == 3时，则相应的报文段立即重传，不会再等超时计时器超时时再重传，接下来执行快恢复算法
问题： 重传后那丢失之前的数据包都收到了，那接收方重复确认时收到了之后的报文段吗
收到了
快恢复
ssthresh 和 cwnd值为当前窗口的一半， 执行拥塞避免算法
也有一些把cwnd = 新的sstresh +3
对称加密和非对称加密的区别
对称加密
加密和解密使用的秘匙是同一个
优点：算法公开，计算量小，加密速度快，加密效率高
缺点：数据传送前，双方必须商定好密匙，保存。如果一方密匙泄露被黑客拦截，则加密信息不安全，每次使用对称加密算法，都需要使用其他人不知道的唯一密匙，是的双方拥有的密匙数量大
常见： DES AES 3DES
非对称加密
需要公开密匙和私有密匙，一方加密，另一方的密匙就解密
过程： 甲方生成密匙 ，将其中一把作为共有的并向其他方公开，得到公有密匙的乙方使用该密匙对机密信息进行加密后发送给甲方，甲方再用私有的密匙对加密信息进行解密
优点：安全
缺点：速度慢
常见：RSA ECC
MD5
MD5讯息摘要演算法（英语：MD5 Message-Digest Algorithm），一种被广泛使用的密码杂凑函数，可以产生出一个128位bit（16Byte）的散列值（hash value），用于确保信息传输完整一致。
MD5不可逆的原因是其是一种散列函数，使用的是hash算法，在计算过程中原文的部分信息是丢失了的
不过有个地方值得指出的是，一个MD5理论上的确是可能对应无数多个原文的，因为MD5是有限多个的而原文可以是无数多个。比如主流使用的MD5将任意长度的“字节串映射为一个128bit的大整数(长度始终固定)。也就是一共有2128种可能，大概是3.4*1038，这个数字是有限多个的，而但是世界上可以被用来加密的原文则会有无数的可能性。
用途
防止被篡改
防止直接看到明文 ---- 前后比较
现在很多网站在数据库存储用户的密码的时候都是存储用户密码的MD5值。这样就算不法分子得到数据库的用户密码的MD5值，也无法知道用户的密码。（比如在UNIX系统中用户的密码就是以MD5（或其它类似的算法）经加密后存储在文件系统中。当用户登录的时候，系统把用户输入的密码计算成MD5值，然后再去和保存在文件系统中的MD5值进行比较，进而确定输入的密码是否正确。通过这样的步骤，系统在并不知道用户密码的明码的情况下就可以确定用户登录系统的合法性。这不但可以避免用户的密码被具有系统管理员权限的用户知道，而且还在一定程度上增加了密码被破解的难度。）
防止抵赖--数字签名
文件秒传(检查文件MD5是否相同), 若相同则大概率已经有相同文件在库中
过程
- 对MD5算法简要的叙述可以为：MD5以512位分组来处理输入的信息，且最终要预留出488位(不够则补位，第一位为1之后为0)(为什么是488？因为最后还要添加64位来记录原始数据长度，之后总数据长度为512整数倍，即M * 64 Byte)
- 准备4个幻数 每个4个字节
- 对每64Byte 通过四个幻数对其进行运算
- 输出4个幻数的最终结果即可
为何已不再安全
抗碰撞性被验证无效：不指定MD5 也不指定消息，只要有方法找出两个MD5值相同的数据就算成功
王小云：发现找到大量MD5碰撞对的方法(但碰撞对基本无意义) -> Marc Stevens: 一个内容(可能是特定的?)生成另外两个MD5值一样但内容不一样的数据，**且都是有意义的. (前缀有效)(例如图片)；可自由选择前缀消息内容，即前缀不一样但MD5也一样，称为选择前缀碰撞。
为何MD5还在使用
抗第二原像攻击(抗弱碰撞性)未被打破：即对于指定的数据，找出与其MD5相同但内容不同的另一段数据
攻击者无法直接控制原始文件(无法逆向源程序)和MD5值，所以无法通过选择前缀碰撞，而只能用第二原像攻击且要保证找到的消息有意义。但这也不是完全安全的。
另外的问题
内网和外网的区别
内网又称局域网（Local Area Network，LAN）是指在某一区域内由多台计算机互联成的计算机组。一般是方圆几千米以内。
局域网是封闭型的，可以由办公室内的两台计算机组成，也可以由一个公司内的上千台计算机组成。
局域网主要特点是：
1、覆盖的地理范围较小，只在一个相对独立的局部范围内联，如一座或集中的建筑群内。
2、使用专门铺设的传输介质进行联网，数据传输速率高（10Mb/s～10Gb/s）
3、通信延迟时间短，可靠性较高
4、局域网可以支持多种传输介质
外网又被称为广域网（WAN），就是我们通常所说的Internet，它是一个遍及全世界的网络。它可以连接极其大的物理范围，属于远程性的网络，已经实现了跨国互联，局域网以及城域网都远远比不上外网，外网是许多的计算机相互之间用线路连接形成的。
目前为止，因特网就是世界上最大的外网，它的覆盖范围无可匹敌。一些相隔较远的设备就需要外网的连接，这些设备中比较常见的是路由器和交换机 。
外网还分为了好几类，按照网络的使用类型可以分成公共传输、专用传输和无线传输三类网络传输。
迅雷为什么会员可以加速那么快？
QQ传文件为什么那么快？
UDP、TCP、端口号
TCP、UDP可以同时绑定相同端口吗
能，主机收到数据包后会拆解IP报头获得协议，如果是TCP则交给绑定该TCP端口的应用程序处理 UDP交给绑定了UDP该端口的应用程序处理
多个TCP进程能绑定同一个端口吗
不能。TCP 服务进程需要绑定一个 IP 地址和一个端口，然后就监听在这个地址和端口上，等待客户端连接的到来(所以要主机上的IP地址和端口有一个不相同才能绑定)
客户端同一个端口能连接不同服务器的TCP服务吗
能。在客户端执行 connect 函数的时候，只要客户端连接的服务器不是同一个，内核允许端口重复使用。
参考文章：