计算机网络整理

OSI七层体系结构，理论上的国际标准

TCP/IP事实上的标准

五层体系结构只是为了理论研究，没有实际意义 

• 应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
• 表示层（数据）：主要解决用户信息的语法表示问题，如加密解密
• 会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的
• 传输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等
• 网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的传输
• 数据链路层（帧）：将上层数据封装成帧，用MAC地址访问媒介，错误检测与修正
• 物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等
• 各层协议：
• 应用层：HTTP、TELNET、FTP、SMTP
• 传输层：TCP、UDP
• 网络层：IP、ICMP
• 数据结构：ppp

各层使用哪个交换设备：

网关：应用层、传输层

网关在传输层上以实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。

网关的结构也和路由器类似，不同的是互连层。网关既可以用于广域网互连，也可以用于局域网互连

【重点】路由器：网络层

路由选择、存储转发

【重点】交换机：数据链路层、网络层

识别数据包中的 MAC 地址信息，根据 MAC 地址进行转发，并将这些 MAC 地址与对应的端口记录在自己内部的一个地址表中。

网桥：数据链路层

将两个 LAN 连起来，根据 MAC 地址来转发帧。

集线器（Hub）：物理层

纯硬件设备，主要用来连接计算机等网络终端。

中继器：物理层

在比特级别对网络信号进行再生和重定时，从而使得它们能够在网络上传输更长的距离。

 交换机是什么？

在计算机网络系统中，交换机是针对共享工作模式的弱点而推出的。交换机拥有一条高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条背部总线上，当控制电路收到数据包以后，处理端口会查找内存中的地址对照表以确定目的 MAC（网卡的硬件地址）的 NIC（网卡）挂接在哪个端口上，通过内部交换矩阵迅速将数据包传送到目的端口。目的 MAC 若不存在，交换机才广播到所有的端口，接收端口回应后交换机会“学习”新的地址，并把它添加入内部地址表中。

交换机工作于 OSI 参考模型的第二层，即数据链路层。交换机内部的 CPU 会在每个端口成功连接时，通过 ARP 协议学习它的 MAC 地址，保存成一张 ARP 表。在今后的通讯中，发往该 MAC 地址的数据包将仅送往其对应的端口，而不是所有的端口。因此，交换机可用于划分数据链路层广播，即冲突域；但它不能划分网络层广播，即广播域。

 路由器是什么？

路由器（Router），是一种计算机网络设备，提供了路由与转发两种重要机制，可以决定数据包从来源端到目的端所经过的路由路径（host 到 host 之间的传输路径），这个过程称为路由；将路由器输入端的数据包移送至适当的路由器输出端(在路由器内部进行)，这称为转发。所以，路由器的一个作用是连通不同的网络，另一个作用是选择信息传送的线路。

路由工作在 OSI 模型的第三层 —— 即网络层，例如 IP 协议。当然，这也是路由器与交换器的差别，路由器是属于 OSI 第三层的产品，交换器是 OSI 第二层的产品(这里特指二层交换机)。

常见的路由选择协议，以及它们的区别？

常见的路由选择协议有：RIP 协议、OSPF 协议。

 

• RIP 协议：底层是贝尔曼福特算法，它选择路由的度量标准（metric)是跳数，最大跳数是 15 跳。如果大于 15 跳，它就会丢弃数据包。
• OSPF 协议：底层是迪杰斯特拉算法，是链路状态路由选择协议，它选择路由的度量标准是带宽，延迟。

详细说明 Keepalived 的故障切换工作原理？

这种故障切换，是通过 VRRP 协议来实现的。

 

• 主节点会按一定的时间间隔发送心跳信息的广播包（心跳检测），告诉备节点自己的存活状态信息。
• 当主节点发生故障时，备节点在一段时间内就收到广播包，从而判断主节点出现故障，因此会调用自身的接管程序来接管主节点的 IP 资源及服务。
• 当主节点恢复时，备节点会主动释放资源，恢复到接管前的状态，从而来实现主备故障切换

IP

IP 地址的分类？

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

IP 地址编址方案将IP地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。

每个 IP 地址包括两个标识码（ID），即网络 ID 和主机 ID 。同一个物理网络上的所有主机都使用同一个网络 ID ，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：

 

• A 类地址：以 0 开头，第一个字节范围：0~127 。
• B 类地址：以 10 开头，第一个字节范围：128~191 。
• C 类地址：以 110 开头，第一个字节范围：192~223。
• D 类地址：以 1110 开头，第一个字节范围：224~239 。
• E 类地址：以 1111 开头，保留地址。

• ? IP 地址与物理地址的区别？

• 物理地址(MAC 地址)，是数据链路层和物理层使用的地址。
• IP 地址是网络层和以上各层使用的地址，是一种逻辑地址。
• 其中 ARP 协议用于 IP 地址与物理地址的对应。

网络层的 ARP 协议工作原理？

网络层的 ARP 协议完成了 IP 地址与物理地址的映射。

首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：

• 如果有，就直接将数据包发送到这个 MAC 地址。
• 如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的 MAC 地址。此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 I P地址一致。
  • 如果不相同，就忽略此数据包。
  • 如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中(如果 ARP 表中已经存在该 IP 的信息，则将其覆盖)，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址。
    • 源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。
    • 如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

注意，在 OSI 模型中 ARP 协议属于链路层；而在 TCP/IP 模型中，ARP 协议属于网络层。

 

简述一下 ping 的原理？

一般在网络不通的时候，大家会用 ping 测一下网络是否通畅。

ping 是基于 ICMP 协议工作的。ICMP 全称 Internet Control Message Protocol ，就是互联网控制报文协议。这里的关键词是“控制”，那具体是怎么控制的呢？ 网络包在异常负责的网络环境中传输时，会遇到各种问题，当遇到问题时，要传出消息，报告情况，这样才能调整传输策略。

ICMP 报文是封装在 IP 包里面的。因为传输指令的时候，肯定需要源地址和目标地址。如下图：

什么是 Traceroute ？

Traceroute 是构建在 ICMP 协议之上的应用。

Traceroute ，是用来侦测主机到目的主机之间所经路由情况的重要工具，也是最便利的工具。

前面说到，尽管 ping 工具也可以进行侦测，但是，因为 IP 头的限制，ping 不能完全的记录下所经过的路由器。所以Traceroute 正好就填补了这个缺憾。

Traceroute 的原理是非常非常的有意思。

• 它受到目的主机的 IP 后，首先给目的主机发送一个 TTL=1（还记得 TTL 是什么吗？）的 UDP(后面就知道 UDP是什么了)数据包，而经过的第一个路由器收到这个数据包以后，就自动把 TTL 减1，而 TTL 变为 0 以后，路由器就把这个包给抛弃了，并同时产生 一个主机不可达的 ICMP 数据报给主机。
• 主机收到这个数据报以后再发一个 TTL=2 的 UDP 数据报给目的主机，然后刺激第二个路由器给主机发 ICMP 数据 报。如此往复直到到达目的主机。

这样，traceroute 就拿到了所有的路由器 IP 。从而避开了 IP 头只能记录有限路由 IP 的问题。

有人要问，我怎么知道 UDP 到没到达目的主机呢？

这就涉及一个技巧的问题，TCP 和 UDP 协议有一个端口号定义，而普通的网络程序只监控少数的几个号码较小的端口，比如说 80、23 等等。而 traceroute 发送的是端口号 >30000(真变态) 的 UDP 包，所以到达目的主机的时候，目的主机只能发送一个端口不可达的 ICMP 数据报给主机。主机接到这个报告以后就知道，目标主机到了。

? 很多情况下，在我们 ping 不通目标地址时，会尝试使用 traceroute 命令，看看是否在中间哪个 IP 无法访问。

TCP

TCP 是什么？

TCP(Transmission Control Protocol)，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。主要特点如下：

TCP 是面向连接的。

就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接

每一条 TCP 连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）。

TCP 对应的应用层协议？

 

• FTP ：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。
• Telnet ：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。
• 邮箱
  • SMTP ：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。
  • POP3 ：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Foxmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是 163 邮箱就没有必要先进入网易网站，再进入自己的邮箱来收信）。
• HTTP ：从 Web 服务器传输超文本到本地浏览器的传送协议。
• TCP 提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。
• TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据。

• 面向字节流。

  TCP 中的“流”（Stream），指的是流入进程或从进程流出的字节序列。

  “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

详细来说，步骤如下：

第一次握手：Client 将标志位 SYN=1 ，随机产生一个值 seq=J ，并将该数据包发送给 Server 。此时，Client 进入SYN_SENT 状态，等待 Server 确认。 第二次握手：Server 收到数据包后由标志位 SYN=1 知道Client请求建立连接，Server 将标志位 SYN 和 ACK 都置为 1 ，ack=J+1，随机产生一个值 seq=K ，并将该数据包发送给 Client 以确认连接请求，Server 进入 SYN_RCVD 状态。此时，Server 进入 SYC_RCVD 状态。 第三次握手：Client 收到确认后，检查 ack 是否为 J+1 ，ACK 是否为 1 。

• 如果正确，则将标志位 ACK 置为 1 ，ack=K+1 ，并将该数据包发送给 Server 。此时，Client 进入 ESTABLISHED 状态。
• Server 检查 ack 是否为 K+1 ，ACK 是否为 1 ，如果正确则连接建立成功。此时 Server 进入 ESTABLISHED 状态，完成三次握手，随后 Client 与 Server 之间可以开始传输数据了。

仔细看来，Client 会发起两次数据包，分别是 SYNC 和 ACK ；Server 会发起一次数据包，包含 SYNC 和 ACK 。也就是说，三次握手的过程中，Client 和 Server 互相做了一次 SYNC 和 ACK 。

? 为什么 TCP 连接需要三次握手，两次不可以么，为什么？

为了防止已失效的连接请求报文突然又传送到了服务端，因而产生错误。

客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达 Server 。

• 若不采用“三次握手”，那么只要 Server 发出确认数据包，新的连接就建立了。由于 Client 此时并未发出建立连接的请求，所以其不会理睬 Server 的确认，也不与 Server 通信；而这时 Server 一直在等待 Client 的请求，这样 Server 就白白浪费了一定的资源。
• 若采用“三次握手”，在这种情况下，由于 Server 端没有收到来自客户端的确认，则就会知道 Client 并没有要求建立请求，就不会建立连接。

防止了服务器端的一直等待而浪费资源 

 

? 客户端不断进行请求链接会怎样？

服务器端准备为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认后创建。如果此时客户端一直不确认，会造成 SYN 攻击，即：

SYN 攻击，英文为 SYN Flood ，是一种典型的 DoS/DDoS 攻击。

1、客户端向服务端发送请求连接数据包。 2、服务端向客户端发送确认数据包。

3、客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认。

就是这一步！！！

? 如何检测 SYN 攻击？检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。

? 怎么解决 SYN 攻击呢？答案是只能预防，没有彻底根治的办法，除非不使用 TCP 。方式如下：

 

• 1、限制同时打开 SYN 半链接的数目

  是不是很像我们常用的“限流”。

• 2、缩短 SYN 半链接的 Timeout 时间

  是不是很像我们常用的“超时”。

• 3、关闭不必要的服务。

  酱紫，这个服务就不会被 SYN 攻击连接。

• 4、增加最大半连接数。

• 5、过滤网关防护。
• 6、SYN cookie 技术。

【重要】什么是 TCP 四次挥手？

四次挥手，简单来说，就是：

发送方：我要和你断开连接！ 接收方：好的，断吧。 接收方：我也要和你断开连接！ 发送方：好的，断吧。

如果要正确的理解四次的原理，就需要了解四次挥手过程中的状态变化。

主动方=发送方；被动方=接收方。

状态前面的（主动方）（被动方），表示该状态属于谁。

? 为什么要四次挥手？

TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着：

详细来说，步骤如下：

如下使用 Client 和 Server 的方式，仅仅是为了方便，也是可以从 Server 向 Client 发起。

 

• （主动方）FIN_WAIT_1 ：这个状态要好好解释一下，其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真正含义都是表示等待对方的 FIN 报文。而这两种状态的区别是：
  • FIN_WAIT_1 状态实际上是当 Socket 在 ESTABLISHED 状态时，它想主动关闭连接，向对方发送了 FIN 报文，此时该 Socket 即进入到 FIN_WAIT_1 状态。
  • 而当对方回应 ACK 报文后，则进入到 FIN_WAIT_2 状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK 报文。所以， FIN_WAIT_1 状态一般是比较难见到的，而 FIN_WAIT_2 状态还有时常常可以用 netstat 看到。
• （主动方）FIN_WAIT_2 ：上面已经详细解释了这种状态，实际上 FIN_WAIT_2 状态下的 Socket，表示半连接，也即有一方要求 close 连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK 信息)，稍后再关闭连接。
• （被动方）CLOSE_WAIT ：这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方 close 一个 Socket 后发送 FIN 报文给自己，你系统毫无疑问地会回应一个 ACK 报文给对方，此时则进入到 CLOSE_WAIT 状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close 这个 Socket ，发送 FIN 报文给对方，也即关闭连接。所以你在 CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。
• （被动方）LAST_ACK ：这个状态还是比较容易好理解的，它是被动关闭一方在发送 FIN 报文后，最后等待对方的 ACK 报文。当收到 ACK 报文后，也即可以进入到 CLOSED 可用状态了。

• （主动方）TIME_WAIT ：表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等 2MSL 后即可回到 CLOSED 可用状态了。如果 FIN_WAIT_1 状态下，收到了对方同时带 FIN 标志和 ACK 标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。

  为何一定要等 2MSL ？

  如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的 TCP 报文可能与新 TCP 连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的 TCP 连接的活跃报文全部死翘翘，2MSL 时间可以满足这个需求（尽管非常保守）！

• 当主机 1 发出 FIN 报文段时，只是表示主机 1 已经没有数据要发送了，主机 1 告诉主机 2 ，它的数据已经全部发送完毕了；但是，这个时候主机 1 还是可以接受来自主机 2 的数据；当主机 2 返回 ACK报文段时，表示它已经知道主机 1 没有数据发送了，但是主机 2 还是可以发送数据到主机 1 的。

  因为主机 2 此时可能还有数据想要发送给主机 1 ，所以挥手不能像握手只有三次，而是多了那么“一次”！

• 当主机 2 也发送了 FIN 报文段时，这个时候就表示主机 2 也没有数据要发送了，就会告诉主机 1 ，我也没有数据要发送了，之后彼此就会愉快的中断这次 TCP 连接。

  我们把四次挥手，理解成一次和平的挥手~

• 第四次挥手，Client 收到 FIN 后，此时 Client 进入 TIME_WAIT 状态。接着，Client 发送一个 ACK 给 Server ，确认序号为 N+1 。Server 接收到后，此时 Server 进入 CLOSED 状态，完成四次挥手。
• 第一次挥手：Client 发送一个 FIN=M ，用来关闭 Client 到 Server 的数据传送。此时，Client 进入 FIN_WAIT_1 状态。
• 第二次挥手，Server 收到 FIN 后，发送一个 ACK 给 Client ，确认序号为 M+1（与 SYN 相同，一个 FIN 占用一个序号）。此时，Server 进入 CLOSE_WAIT 状态。注意，TCP 链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
• 第三次挥手，Server 发送一个 FIN=N ，用来关闭 Server 到 Client 的数据传送。此时 Server 进入 LAST_ACK 状态。

【重要】TCP 数据如何传输？

建立连接后，两台主机就可以相互传输数据了。如下图所示：

 

• 上图给出了主机 A 分 2 次（分 2 个数据包）向主机 B 传递 200 字节的过程。
• 首先，主机 A 通过 1 个数据包发送 100 个字节的数据，数据包的 Seq 号设置为 1200 。主机 B 为了确认这一点，向主机 A 发送 ACK 包，并将 Ack 号设置为 1301 。
  • 为了保证数据准确到达，目标机器在收到数据包（包括 SYN 包、FIN 包、普通数据包等）包后必须立即回传 ACK 包，这样发送方才能确认数据传输成功。
  • 此时 Ack 号为 1301 而不是 1201，原因在于 Ack 号的增量为传输的数据字节数。假设每次 Ack 号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确 100 字节全部正确传递还是丢失了一部分，比如只传递了 80 字节。因此按如下的公式确认 Ack 号：Ack 号 = Seq 号 + 传递的字节数 + 1 。
    • 与三次握手协议相同，最后加 1 是为了告诉对方要传递的 Seq 号。

? TCP 数据传输丢失怎么办？

这个问题，也可以改成提问，什么是 TCP 重传。

因为各种原因，TCP 数据包可能存在丢失的情况，TCP 会进行数据重传。如下图所示：

 

• 上图表示通过 Seq 1301 数据包向主机 B 传递 100 字节的数据，但中间发生了错误，主机 B 未收到。经过一段时间后，主机 A 仍未收到对于 Seq 1301 的 ACK 确认，因此尝试重传数据。为了完成数据包的重传，TCP 套接字每次发送数据包时都会启动定时器，如果在一定时间内没有收到目标机器传回的 ACK 包，那么定时器超时，数据包会重传。上图演示的是数据包丢失的情况，也会有 ACK 包丢失的情况，一样会重传。

• 重传超时时间(RTO，Retransmission Time Out)

  这个值太大了会导致不必要的等待，太小会导致不必要的重传，理论上最好是网络 RTT 时间，但又受制于网络距离与瞬态时延变化，所以实际上使用自适应的动态算法（例如 Jacobson 算法和 Karn 算法等）来确定超时时间。

  往返时间（RTT，Round-Trip Time）表示从发送端发送数据开始，到发送端收到来自接收端的 ACK 确认包（接收端收到数据后便立即确认），总共经历的时延。

• 重传次数

  TCP 数据包重传次数，根据系统设置的不同而有所区别。有些系统，一个数据包只会被重传 3 次，如果重传 3 次后还未收到该数据包的 ACK 确认，就不再尝试重传。但有些要求很高的业务系统，会不断地重传丢失的数据包，以尽最大可能保证业务数据的正常交互。

  最后需要说明的是，发送端只有在收到对方的 ACK 确认包后，才会清空输出缓冲区中的数据。

【重要】什么是 TCP 滑动窗口？

在看 TCP 滑动窗口的概念之前，我们先来看看它出现的背景？

将 TCP 与 UDP 这样的简单传输协议区分开来的是，它传输数据的质量。TCP 对于发送数据进行跟踪，这种数据管理需要协议有以下两大关键功能：

• 可靠性：保证数据确实到达目的地。如果未到达，能够发现并重传。
• 数据流控：管理数据的发送速率，以使接收设备不致于过载。

要完成这些任务，整个协议操作是围绕滑动窗口 + 确认机制来进行的。因此，理解了滑动窗口，也就是理解了 TCP 。

那么，到底什么是 TCP 滑动窗口呢？

滑动窗口协议，是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。

TCP 的滑动窗口解决了端到端的流量控制问题，允许接受方对传输进行限制，直到它拥有足够的缓冲空间来容纳更多的数据。

 

 

TCP的滑动窗口机制 
      TCP这个协议是网络中使用的比较广泛，他是一个面向连接的可靠的传输协议。既然是一个可靠的传输协议就需要对数据进行确认。TCP协议里窗口机制有2种：一种是固定的窗口大小；一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据。对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。

      TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。 假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送序列号为1、2、3的三个数据包，接收方设备成功接收数据包，用序列号4确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。

看这个场景, 老师说一段话, 学生来记.

老师说"从前有个人, 她叫马冬梅. 她喜欢他, 而他却喜欢她."

学生写道"从前有..". "老师你说的太快我跟不上"

于是他们换了一种模式.

老师说"从"

学生写"从". 学生说"嗯"

老师说"前"

学生写"前". 学生说"嗯"

老师说"今天我还想早点下班呢..."

于是他们换了一种模式.

老师说"从前有个人"

学生写"从前有个人". 学生说"嗯"

老师说"她叫马冬梅".

学生写"她叫马...梅". 学生说"马什么梅?"

老师说"她叫马冬梅".

学生写"她叫马冬...". 学生说"马冬什么?"

老师"....."

学生说"有的时候状态好我能把5个字都记下来, 有的时候状态不好就记不下来. 我状态不好的时候你能不能慢一点. "

于是他们换了一种模式

老师说"从前有个人"

学生写"从前有个人". 学生说"嗯, 再来5个"

老师说"她叫马冬梅"

学生写"她叫马..梅". 学生说"啥?重来, 来2个"

老师说"她叫"

学生写"她叫". 学生说"嗯,再来3个"

老师说"马冬梅".

学生写"马冬梅". 学生说"嗯, 给我来10个"

老师说"她喜欢他,而他却喜欢她"

学生写...

所以呢

第一种模式简单粗暴, 发的只管发, 收的更不上.

第二种模式稳定却低效, 每发一个, 必须等到确认才再次发送, 等待时间很多.

第三种模式提高了效率, 分组进行发送, 但是分组的大小该怎么决定呢?

第四中模式才是起到了流控的作用, 接收方认为状态好的时候, 让发送方每次多发一点. 接收方认为状态不好的时候(阻塞), 让发送方每次少发送一点.

我们可以看下面一张图来分析一下固定窗口大小有什么问题。 
 
这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。  
我们看看滑动窗口是如何工作的。我们看下面几张图。 

 

 
首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2 。 
 

这个时候发送方发送2个数据。 

 
看到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了这个时候开始发送第5个数据。 
这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变话，并不是第一次协商好了以后就永远不变了。                 
滑动窗口协议 
滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 
只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。    
收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。    
当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。

TCP 协议如何来保证传输的可靠性？

TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。

在一个 TCP 连接中，仅有两方进行彼此通信。 而字节流服务意味着两个应用程序通过 TCP 链接交换 8bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。

对于可靠性，TCP 通过以下方式进行保证：

• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据。
• 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TC P报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层。
• 丢弃重复数据：对于重复数据，能够丢弃重复数据。
• 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。
• 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
• 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
• 制协议是可变大小的滑动窗口协议。

什么是 TCP 拥堵？

计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。

? 怎么解决 TCP 拥堵？

通过拥塞控制来解决。拥堵控制，就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。

拥塞控制的方法主要有以下四种：

 

• 1、慢开始。
• 2、拥塞避免。
• 3、快重传。
• 4、快恢复。

UDP

UDP 是什么？

UDP（User Data Protocol，用户数据报协议），是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去。

主要特点如下：

UDP 是无连接的。 UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）。 UDP 是面向报文的。

UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低。

对实时应用很有用，如 直播，实时视频会议等

UDP 支持一对一、一对多、多对一和多对多的交互通信。

UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

所谓的“数据报模式”，是指 UDP 发送端调用了几次 write ，接收端必须用相同次数的 read 读完。

? 为什么 TCP 叫数据流模式？ UDP 叫数据报模式？

所谓的“流模式”，是指TCP 发送端发送几次数据和接收端接收几次数据是没有必然联系的。

TCP(Transmission Control Protocol)和 UDP(User Datagram Protocol) 协议属于传输层协议，它们之间的区别包括：

【重要】TCP 与 UDP 的区别

这个问题，上面在介绍 TCP 和 UDP 都提到了，就是做了整合哈。

UDP 对应的应用层协议？

 

• UDP 是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。
• 原因：这是因为 UDP 是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。
• 比如你通过 TCP 连接给另一端发送数据，你只调用了一次 write ，发送了 100 个字节，但是对方可以分 10 次收完，每次 10 个字节；你也可以调用 10 次 write ，每次 10 个字节，但是对方可以一次就收完。
• 原因：这是因为 TCP 是面向连接的，一个 Socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。
• TCP 是面向连接的；UDP 是无连接的。
• TCP 是可靠的；UDP 是不可靠的。
• TCP 只支持点对点通信；UDP 支持一对一、一对多、多对一、多对多的通信模式。
• TCP 是面向字节流的；UDP 是面向报文的。
• TCP 有拥塞控制机制；UDP 没有拥塞控制，适合媒体通信。
• TCP 首部开销(20 个字节)，比 UDP 的首部开销(8 个字节)要大。
• DNS ：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。
• SNMP ：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
• TFTP(Trivial File Transfer Protocol)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

DNS

DNS 是什么？

域名解析，www.xxx.com 转换成 IP ，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。 DNS 协议运行在 UDP 协议之上，使用端口号 53 。

DNS 使用什么协议？

参见 《DNS使用的是 TCP 协议还是 UDP 协议》 文章。

既使用 TCP 又使用 UDP 。

主机解析域名的顺序？

 

• 区域传送时使用 TCP 协议。

  • 辅域名服务器会定时（一般时 3 小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用 TCP 而不是 UDP ，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
  • TCP 是一种可靠的连接，保证了数据的准确性。

• 域名解析时使用 UDP 协议。

  • 客户端向 DNS 服务器查询域名，一般返回的内容都不超过 512 字节，用 UDP 传输即可。

    UDP 报文的最大长度为 512 字节。

  • 不用经过 TCP 三次握手，这样 DNS 服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向 DNS 服务器查询的时候使用 TCP ，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。

• 找 DNS 服务器(本地域名、顶级域名、根域名)
  • 迭代查询
  • 递归查询
• 浏览器缓存
• 找本机的 hosts 文件
• 路由缓存

HTTP

HTTP 是什么？

HTTP 协议，是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

主要特点如下：

 

• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST 等等。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
• 数据格式灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。

• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

  主要指的是不使用 Keep-Alive 机制的情况下。

• 无状态：HTTP 协议是无状态协议。无状态，是指协议对于事务处理没有记忆能力。无状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

  无状态，所以更容易做服务的扩容，支撑更大的访问量。

• 支持 B/S 及 C/S 模式。

  另外，HTTP 协议已经不仅仅使用在浏览器上。在前后端分离的架构中，又或者微服务架构的内部通信中，HTTP 因为其数据格式的通用性，和语言无关，被大规模使用。

HTTP 协议包括哪些请求？

GET: 对服务器资源的简单请求。 POST: 用于发送包含用户提交数据的请求。 HEAD：类似于 GET 请求，不过返回的响应中没有具体内容，用于获取报头。

? GET 和 POST 的区别？

请求方式	数据位置	明文密文	数据安全	长度限制	应用场景
GET	HTTP 请求的 path 中	明文	不安全	长度较小，一般 2k	查询数据
POST	HTTP 请求 body 中	可明可密	安全	支持较大数据传输	修改数据

 

• GET 请求可被缓存；POST 请求不会被缓存。
• GET 请求可被收藏为书签；POST 不能被收藏为书签。

• GET在浏览器回退时是无害的，而POST会再次提交请求。

• GET产生的URL地址可以被Bookmark，而POST不可以。

• GET请求会被浏览器主动cache，而POST不会，除非手动设置。

• GET请求只能进行url编码，而POST支持多种编码方式。

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• GET请求在URL中传送的参数是有长度限制的，而POST么有。

• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

• GET参数通过URL传递，POST放在Request body中。

HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。 

那么，“标准答案”里的那些区别是怎么回事？

在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。

但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？

在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。

好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。 

你以为本文就这么结束了？

我们的大BOSS还等着出场呢。。。

这位BOSS有多神秘？当你试图在网上找“GET和POST的区别”的时候，那些你会看到的搜索结果里，从没有提到他。他究竟是什么呢。。。

GET和POST还有一个重大区别，简单的说：

GET产生一个TCP数据包；POST产生两个TCP数据包。

长的说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？

1. GET与POST都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

 

 

• • 对于 GET 方式的请求，浏览器会把 HTTP header 和 data 一并发送出去，服务器响应 200（返回数据）。
  • 而对于 POST，浏览器先发送 header ，服务器响应 100 continue ，浏览器再发送 data ，服务器响应 200 ok（返回数据）。

  也就是说，GET 只需要汽车跑一趟就把货送到了，而 POS T得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

  ps：不过要注意，POST 具体发几次，也和浏览器的实现有关系。例如：Firefox 只发一次。
  ps2：据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的 TCP 在验证数据包完整性上，有非常大的优点。

• PUT：传说中请求文档的一个版本。
• DELETE：发出一个删除指定文档的请求。
• TRACE：发送一个请求副本，以跟踪其处理进程。
• OPTIONS：返回所有可用的方法，检查服务器支持哪些方法。
• CONNECT：用于 SSL 隧道的基于代理的请求。

HTTP 有哪些状态码？

 

• 1×× : 请求处理中，请求已被接受，正在处理
• 2×× : 请求成功，请求被成功处理
  • 200 OK // 客户端请求成功
• 3×× : 重定向，要完成请求必须进行进一步处理
  • 301 Moved Permanently // 永久重定向,使用域名跳转
  • 302 Found // 临时重定向,未登陆的用户访问用户中心重定向到登录页面
• 4×× : 客户端错误，请求不合法
  • 400 Bad Request // 客户端请求有语法错误，不能被服务器所理解
  • 401 Unauthorized // 请求未经授权，这个状态代码必须和 WWW-Authenticate 报头域一起使用
  • 403 Forbidden // 服务器收到请求，但是拒绝提供服务
  • 404 Not Found // 请求资源不存在，eg：输入了错误的 URL
• 5×× : 服务器端错误，服务器不能处理合法请求
  • 500 Internal Server Error // 服务器发生不可预期的错误
  • 503 Server Unavailable // 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP、TCP、Socket 的关系是什么？

TCP/IP 代表传输控制协议/网际协议，指的是一系列协议族。 HTTP 本身就是一个协议，是从 Web 服务器传输超文本到本地浏览器的传送协议。

综上所述：

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

• 需要 IP 协议来连接网络
• TCP 是一种允许我们安全传输数据的机制，使用 TCP 协议来传输数据的 HTTP 是 Web 服务器和客户端使用的特殊协议。
• HTTP 基于 TCP 协议，所以可以使用 Socket 去建立一个 TCP 连接。
• Socket 是 TCP/IP 网络的 API ，其实就是一个门面模式，它把复杂的 TCP/IP 协议族隐藏在 Socket 接口后面。对用户来说，一组简单的接口就是全部，让 Socket 去组织数据，以符合指定的协议。