计算机网络扫盲
| 应用程序 | FTP | TFTP | TELNET | SMTP | DNS | HTTP | SSH | MYSQL |
|---|---|---|---|---|---|---|---|---|
| 熟知端口 | 21,20 | 69 | 23 | 25 | 53 | 80 | 22 | 3306 |
| 传输层协议 | TCP | UDP | TCP | TCP | UDP | TCP | TCP | TCP |
网络层
IP地址分类
简介
IP地址由四段组成，每个字段是一个字节，即4个字节、 每个字节有8位，最大值是255(=256：0~255)。
IP地址由两部分组成，即网络地址和主机地址，二者是主从关系：
- 网络号 net-id，它标志主机（或路由器）所连接到的网络，网络地址表示其属于互联网的哪一个网络
- 主机号 host-id，它标志该主机（或路由器），主机地址表示其属于该网络中的哪一台主机。
IP地址分类
分为A、B、C三类及特殊地址D、E； 全0和全1的都保留不用。
A类（第一位必须是0）：
地址范围：1.0.0.1 - 126.255.255.254 （0000 0001 / 0000 0000/0000 0000/ 0000 0001 ~ 0111 1110/ 1111 1111 / 1111 1111 / 1111 1110）
地址范围：1.0.0.0 - 126.255.255.255 （加入全0和全1）
网络范围：1~126
默认子网掩码:255.0.0.0 或 0xFF 00 00 00
私有号段：10.0.0.0-10.255.255.255
前1个字节(8位)为网络号，后3个字节(24位)为主机号。
最大主机数：
最大网络数：
126个
全0全1的地址不可分配，作为保留地址。 上面减2也是这个原因。
B类（前两位固定为10）
- 地址范围：128.0.0.1 ~ 191.255.255.254
- 网络号范围：128.0 ~ 191.255 （可用范围）
- 默认子网掩码：255.255.0.0 ~ 0xFF FF 00 00
- 私有号段：172.16.0.0 ~ 172.31.255.255
- 最大网络数：
（16位去掉两位)
- 最大主机数：
一般用于中等规模网络。
C类（前3位固定为110）
- 地址范围：192.0.0.1 ~ 233.255.255.254
- 网络号范围：192.0.0~223.255.255
- 子网掩码：255.255.255.0 或 0xFF FF FF00 (十六进制)
- 私有号段：192.168.0.0-192.168.255.255
- 最大网络数：
（24位去掉3位)
- 最大主机数：$2^8 - 2$
一般用于小型网络。
D类（前四位固定为1110）
地址范围：224.0.0.1-239.255.255.254
是多播地址。该类IP地址的最前面为“1110”，所以地址的网络号取值于224~239之间。
E类（前四位固定为1111）
是保留地址。该类IP地址的最前面为“1111”，所以地址的网络号取值于240~255之间。
运输层
TCP
概述
TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种端点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80。
三次握手
三次握手需要确认双方都发送接收正常
第一次握手：client发送 SYN 假设seq = j
client什么都确认不了；server 确认对方发送正常，自己接收正常
第二次握手：server收到syn后，发送SYN与ACK给client， syn = k , ack = j + 1
client 确认自己发送正常，接收正常，对方发送正常，接收正常；server确认对方发送正常，自己接收正常
第三次握手：client收到 syn k，ack = j + 1后，返回 ack = k + 1 表示收到了
cilent确认自己发送正常，接收正常，对方发送正常，接收正常；
确认号是序列号加一。
第2次握手传回了ACK，为什么还要传回SYN？
接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。
而回传SYN则是为了建立并确认从服务端到客户端的通信。
SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。
为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。
服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
四次挥手
- 第一次挥手：client 发送FIN，seq = k。告诉server我要关闭数据连接
- 第二次挥手：server收到FIN，并回传seq = k+1。告诉client我知道你要关闭了
- 第三次挥手：server发出FIN，seq= j , 告诉client我数据发完了，
- 第四次挥手：client回传ack = j + 1，表示知道你数据传完了
可靠传输的保证方式
https://blog.csdn.net/zqxf123456789/article/details/107744691
- 应用数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
- 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
- TCP 的接收端会丢弃重复的数据。
流量控制
TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。
当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
TCP 使用的流量控制协议是可变大小的滑动窗口协议。
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
窗口字段占两个字节，故接受段最大能提供65535个字节的缓存。
拥塞控制
当网络拥塞时，减少数据的发送。
TCP 利用滑动窗口实现流量控制。
流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络中发生了什么。
一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。
在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大…
怎么知道当前网络是否出现了拥塞呢？
只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。
为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
拥塞控制主要是四个算法，在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生：
慢开始：当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
那慢启动涨到什么时候是个头呢？
有一个叫慢启动门限
ssthresh（slow start threshold）状态变量。- 当
cwnd<ssthresh时，使用慢启动算法。 - 当
cwnd>=ssthresh时，就会使用「拥塞避免算法」。
- 当
拥塞避免：让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1。
超时重传：当发生了「超时重传」，则就会使用拥塞发生算法。这个时候，sshresh 和 cwnd 的值会发生变化：
ssthresh设为cwnd/2cwnd重置为1
接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是一旦「超时重传」，马上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。
快重传与快恢复（fast retransmit and recovery，FRR）：没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。
有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。
如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。
有了 FRR，就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。
在这种情况下，
ssthresh和cwnd如下变化：cwnd = cwnd/2，也就是设置为原来的一半;ssthresh = cwnd;- 进入快速恢复算法
进入快速恢复算法如下：
- 拥塞窗口
cwnd = ssthresh + 3（ 3 的意思是确认有 3 个数据包被收到了） - 重传丢失的数据包
- 如果再收到重复的 ACK，那么 cwnd 增加 1
- 如果收到新数据的 ACK 后，设置 cwnd 为 ssthresh，接着就进入了拥塞避免算法
拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1
ARQ协议
自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。
它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。
如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。
停止等待ARQ协议
基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。
优点：简单；缺点：信道利用率低，等待时间长。
无差错情况：发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。
出现差错情况（超时重传）：
超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。
因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。
这种自动重传方式常称为 自动重传请求 ARQ 。
另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。
连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。
确认丢失和确认迟到
- 确认丢失 ：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
- 确认迟到 ：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。
连续ARQ协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
优缺点：
- 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
- 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。
Http
状态码
| 类别 | 描述 |
|---|---|
| 200 (OK) | 请求正常处理 |
| 204 (No Content) | 请求处理成功，但没有资源返回（不包含实体的主体部分） |
| 206 (Partial Content) | 请求资源某一部分 |
| 301 (Moved Permanently) | 亥状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI |
| 302 (Found) | 状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问 |
| 303 (See Other) | 该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源 |
| 304 (Not Modified) | 该状态码表示客户端发送附带条件的时，服务器端允许请求访问资源，但未满足条件的情况，请求报文中含有条件限定的首部。 |
| 307 (Temporaray Redirect) | 临时重定与302 Found有着相同的含义。尽管302标准禁止P0ST变换成GET，但实际使用时大家并不遵守 |
| 400 (Bad Request) | 状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。 |
| 401 (Unauthorized) | 该状态码表示发送的请求需要有通过HTTP认证（BASIC认证、DIGEST认证）的认证信息 |
| 403 (Forbidden) | 该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了 |
| 404 (Not Found) | 状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。 |
| 500 (Internal Server Error) | 该状态码表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障 |
| 503 (Service Unavailable) | 该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter首部字段再返回给客户端 |
Cookie的由来
Http是无状态的协议，它不对之前的请求和响应的状态进行管理。
假设要求登录认证的web页面本身无法进行状态的管理（不记录已登录的状态），那么每次跳转新页面不是要再次登录，就是要在每次请求报文中附加参数来管理登录状态。
保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了 Cookie技术。Cookie技术通过在请求和响应报文中写入 Cookie信息来控制客户端的状态。
cookie会根据从服务器端发送的响应报文内的一个叫做Set- Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie值后发送出去。
服务器端发现客户端发送过来的 Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
请求报文（没有cookie消息的状态）
1 | GET /reader/ HTTP/1.1 |
响应报文（服务端生成Cookie信息）
1 | HTTP/1.1 200 OK |
HTTP报文
HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。通常，并不一定要有报文主体。
请求报文和响应报文的结构
长连接
在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。
当客户端访问某个HTML或其他类型的Web页包含有其他的web资源（js文件，图片等），每遇到这样一个web资源，浏览器就会重新建立一个HTTP会话。
从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：
1 | Connection:keep-alive |
在使用长连接的情况天，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再访问时，会继续使用这一条已经建立的连接。
