Protocolo TCP / IP del protocolo de red (contenido requerido para la entrevista) - JavaEE Elementary - Detail Maniac

prefacio

El primer conocimiento de IO y la red mencionado anteriormente es relativamente básico y simple, solo para que todos tomen un respiro. . .
La programación de sockets de red es moderadamente difícil y todos pueden aprenderla si la estudian cuidadosamente.
 
La siguiente parte es esta publicación de blog. Lo más básico del principio de red es muy similar al multihilo avanzado , es decir, el ensayo de ocho patas para afrontar la entrevista.

El avance anterior de subprocesos múltiples es puro de ocho patas, y el principio de la red en realidad tiene un contexto relativamente claro.
Comparado con el anterior, es más fácil de entender, pero también es difícil.

---

¡Presta atención a esta publicación de blog, que es casi imprescindible para las entrevistas!

Protocolo TCP/IP

A continuación, centrándonos en el modelo de cinco capas, comenzamos a comprender estos protocolos de cinco capas en un orden de arriba a abajo.

---

 

capa de aplicación

La capa con la que los programadores tratan con mayor frecuencia, y las otras cuatro capas son los sistemas operativos, los controladores, el hardware y la implementación. No necesitamos preocuparnos. [A menos que sea un ingeniero de sistemas, un ingeniero de desarrollo de controladores. . . 】

En la capa de aplicación, lo más importante es "diseñar e implementar un protocolo de capa de aplicación".
Diseño e implementación de un protocolo de capa de aplicación: inventar un protocolo e implementarlo usted mismo.
 
Pero no quiero dejarme engañar por este asunto, esto en realidad es algo relativamente simple, y también es algo que hago a menudo en el trabajo.

---

 

Varias plantillas de protocolo comunes

xml

XML es un formato de datos relativamente antiguo.
Aunque todavía está en uso ahora, se usa cada vez menos.

xml, es precisamente por su engorroso formato que su popularidad ha ido disminuyendo paulatinamente.
Por lo tanto, xml rara vez se usa como plantilla de diseño para los protocolos de la capa de aplicación.
Ahora usando xml, principalmente como algunos archivos de configuración.
Debido a que el archivo de configuración no necesita transmisión de red, no importa en absoluto, porque el disco duro mecánico no vale nada.

---

 

json

JSON es el formato de datos más popular para diseñar protocolos de capa de aplicación.
Usaremos esto con frecuencia en nuestro trabajo en el futuro.

---

 

Prototampón

Para resolver el problema de json, surgió Protobuffer.
Un Protobuffer es un formato binario de datos.

En los datos de Protobuffer ya no se incluye el nombre de la clave como json, sino que se distingue el significado de cada campo por orden y algunos símbolos especiales.
Al mismo tiempo, se usa un archivo IDL para describir el formato de los datos (lo que significa cada parte), IDL solo tiene el efecto de ayudar al desarrollo y realmente no transmite.
 
Solo se transmiten datos binarios puros.

---

 

resumen

El ámbito de aplicación de json es más amplio que el de Protobuffer.

Por lo general, la eficiencia del desarrollo es más importante que la eficiencia operativa.
 
La eficiencia del desarrollo incluye el desarrollo y la depuración.
 
Si hay un problema con el entorno en línea.
Si se usa json, la solicitud y la respuesta en cuestión se pueden ver de un vistazo.
Si usa protobuffer, datos binarios, definitivamente no hay forma de solucionar el problema con sus ojos.
Para resolver este problema, solo hay una forma: escribir un código de depuración y usarlo para depurar, lo que es más problemático.
 
Esto es lo que llamamos la diferencia en la eficiencia del desarrollo.

---

 

Resumir

Diseñar protocolos de capa de aplicación es algo muy común y no complicado.
Para diseñar el protocolo de la capa de aplicación, el trabajo a realizar
1. Transmitir claramente la información (según los requisitos)
2. Transmitir claramente el modo (consulte las plantillas existentes: xml, json, Protobuffer)
Pero además, la industria también tiene algunos listos -hecho, ya Un protocolo de capa de aplicación ampliamente utilizado y bien diseñado.
(No todo el tiempo, es necesario diseñar desde cero. En muchos casos, puede basarse directamente en el protocolo prefabricado, ligeramente modificado, ligeramente ampliado, para llevar a cabo este tipo de desarrollo secundario)
[Similar al Video de animal fantasma de pila B, es una segunda creación secundaria típica (desarrollo secundario), el producto del uso de videos listos para modificar y editar]
 
Entre los "protocolos listos para usar", el protocolo de capa de aplicación más conocido es HTTP.

Simplemente abra cualquier página web arbitraria, y el proceso interactivo en ella se lleva a cabo a través de HTTP.
Otro ejemplo: abra una aplicación móvil, como Ele.me, Didi Taxi, etc.
En este momento, es probable que el proceso de interacción entre nuestra aplicación móvil y su servidor sea HTTP.

---

 

capa de transporte

Aunque la capa de transporte es implementada por el kernel del sistema operativo, los programadores no necesitan tratar directamente con la capa de transporte, ¡pero la capa de transporte sigue siendo de gran importancia para nosotros! ! !

La programación de red requiere sockets. Una vez que llama a los sockets, el código ingresa al alcance de la capa de transporte.
Si todo va bien, bien.
Una vez que el código tiene algunos errores. Para resolver y comprender estos errores, es necesario cierto conocimiento de la capa de transporte.
El protocolo de la capa de transporte también es una prueba favorita en la entrevista, el protocolo TCP,

Comienza oficialmente lo siguiente.
Hay muchos protocolos en la capa de transporte, los más comunes son UDP y TCP .
A continuación, aprendamos algunos conocimientos específicos en UDP y TCP.

---

 

UDP

Formato del lado del protocolo UDP

Aprender un protocolo es a menudo el estudio del formato del mensaje.
¿Qué aspecto tiene un datagrama UDP? ¡Lo descubrimos!
De hecho, algunas de las características que contiene están aquí.

---

 

Características de UDP

Programación de red (protocolos TCP y UDP )

---

 

Protocolo de capa de aplicación basado en UDP

NFS: Sistema de archivos de red
TFTP: Protocolo trivial de transferencia de archivos
DHCP: Protocolo de configuración dinámica de host
BOOTP: Protocolo de inicio (para inicio de dispositivo sin disco)
DNS: Protocolo de resolución de nombres de dominio

---

 

TCP (énfasis)

TCP, es decir, Transmission Control Protocol, protocolo de control de transmisión. Como su nombre indica, es necesario llevar a cabo un control detallado sobre la transmisión de datos.

TCP es un protocolo muy, muy importante, no solo ampliamente utilizado en el desarrollo real, sino también una pregunta frecuente en las entrevistas.

Formato de segmento de protocolo TCP

所以，我们整体看一下，发现：在真正理解TCP的一些机制之前，这里面的很多信息，以目前的知识储备是无法理解的。
因此，光看报头结构，还不够！！！
还得结合TCP这里面的一些具体的工作机制，进一步理解 TCP是怎么工作的。
然后，才能去明确 TCP报头，这里面都在做些什么。
这就是我们接下来要完成的工作。

---

 

下面，我们就来介绍 TCP 里面的十个核心特性

---

 

第一个机制/特性：确认应答

保证 TCP 可靠传输的核心机制。

在上篇博文网络编程（TCP 与 UDP协议）中，讲到：可靠性是指 发送方发出数据之后，能够知道对方有没有收到数据。
换个说法：
如果发送消息之后，能够知道对方 收到/没收到 数据，就是可靠的。
反之，发送消息之后，不知道对方 收到/没收到 数据，就是不可靠的。

---

所以，我们的TCP就是为了解决这个可靠性问题。
那么，问题来了：怎么解决的呢？怎么知道对方 收没收到数据呢？

关键就是：接收方 收到消息之后，就给发送方返回一个应答报文（ACK - acknowledge），表示自己已经收到了。
 
这就跟平常打电话一样，我说一句话，你回一声嗯，或者回一句话。
这样我们就能知道对方是听到我说的话。【知道对方收到了数据】
如果我们了一大堆，对面什么话都没说。
我们 就会认为对面可能没有听到，然后，就会问：你能听见吗？你怎么不说话？是信号不好吗？【知道对方可能没有收到数据】
 
这里的 “嗯/一句话 的回答”，就是确认应答的关键所在，

---

 

二、超时重传

相当于对确认应答进行了补充 。

确认应答是在网络一切正常的时候，通过 ACK 通知发送方，我收到了。
如果出现了丢包的情况，超时重传机制就要起到效果了。

---

 

小结

基于上述的两个机制，TCP 的可靠性，就得到了有效的保障。
一个是针对 顺利的情况下，它是怎么处理的，这就是确认应答。
一个是 针对 通信丢包了，是怎么处理的，那就是超时重传。
这两者相结合，其实我们就可以解决很多很多的问题。
但是呢！TCP 这样的协议，它是不满足于上述这两点的。
它希望它能做得更好，更加极致。

---

 

下面再来看 第三个机制：连接管理（非常经典的面试题）

连接管理，也是 TCP 保证可靠性的一个机制。

虽然说，它不像上面的两个机制，来得那么直接。
'但是它的存在，也是非常有必要的。

---

连接管理，说具体点：
1、两个设备之间是如何建立连接的？
2、两个设备之间是如何断开连接的？
TCP 连接管理，是网络部分最高频的面试题，没有之一！！！

---

 

1、两个设备之间是如何建立连接的？ - 三次握手

三次握手：客户端和服务器之间，通过 三次交互，完成了建立连接的过程。
这里的“握手”是一个形象比喻。

其实一次握手，就是一次交互的过程。
就是客户端 给 服务器 发了一个数据，这就相当于一次握手。
服务器再给客户端反馈一个数据，这就是另外一次握手。
客户端 根据服务器的反馈，而进行反馈，告诉服务器，它接受到了它的反馈，
一共经历3次，就完成这个三次握手。

---

结论：
三次握手 对于 TCP 可靠传输来说，是非常必要的，尤其是这个“投石问路”的过程，非常重要！

---

 

经典的面试

1、描述 TCP 三次握手的过程。

这个我在前面讲的很明白，说不出去，自己去拿块豆腐，自行了断。
我要说的是：针对这个问题，不要用嘴说！要画图！！！
用嘴说，万一说错了，容易把自己绕进去！
画图更稳。

其实 TCP 三次握手的图，有很多版本。
我推荐的是最简单的一个版本。
还有在 SYN 和 ACK 上面标记上序号 和 确认序号。
还有标记上 TCP 转态转换的。（上面复杂图包含这一条）
还有标记对应的 socket API 的（上面复杂图包含这一条）
等等…
 
主要是因为：这水太深，怕你把握不住。【说实话我也把握不住。】

---

2、为什么握手三次？两次行不行？四次行不行？

首先，4 次是可以的，但是！没必要！
三次握手 本就是一个双向奔赴的过程，本来就是 4次交互。
前面也说到了 中间的那两次是可以合并，没必要分成两次，来降低执行效率。
 
两次，这绝对不行的。
如果是两次，意味着 服务器（乙方），只能确定它大的接收能力是正常的，发送能力是无法确定的；而客户端（甲方）的接收 和 发送能力都是正常的，

此时，服务器对于进行可靠传输，心里是没底的。
因为它的的发送能力是无法保证的。
故，进行第三次握手，就是为了给服务器吃一个定心丸。
告诉它目前没有任何问题，放心大胆的进行后面的操作。

---

 

2、两个设备之间是如何断开连接的？- 四次挥手

<font size4=> 三次握手，就让客户端和服务器之间建立好了连接。
其实建立好连接之后，操作系统内核中，就需要使用一定的数据结构来保存连接相关的信息。

其实理解起来很简单。
客户端 和 服务器之间建立好连接了。
那么这个时候，可能你就要问服务器了，水跟你建立的连接的？
服务器回答：哦，是跟那个客户端建立连接的。

总之，四次挥手，它其实和三次握手起到的效果是有很大区别的！！！
三次握手，是进行可靠性传输之前的验证。
而四次挥手，是为了释放必要的资源。

那么，4次挥手，又是怎么挥的呢？
虽然它的目的 和 三次握手 不同，但是流程非常相似！

其实4次挥手，有复杂的图。（带有状态转换 和 还有TCP状态对应操作系统的API）

---

 

小结

TCP 虽然可靠性是最高的机制，但是TCP也会尽可能的提高效率！！
也就是说：除了刚才的可靠性之外，还回在引入其他的机制来提高传输的效率。

---

 

第四个机制：滑动窗口

滑动窗口存在的意义就是在保证可靠性的前提天，尽量提高传输效率！！！

---

 

五、流量控制

流量控制，是滑动窗口的延伸，目的是为了保证可靠性。

在滑动窗口中，窗口越大（一次传输的数据量），传输速率也就越高。
 
那么，有些朋友就会这么去想：我把窗口弄得越大越好，这样的我们数据传输量就大幅度提升了。
答案：不行！
把窗口弄大，不光要考虑发送方，还得考虑接收方。
如果发送方发送的速度非常快，接收方完全就处理不过来，接收方就会把新接收到的包给丢了。
那么，发送方是不是还得重传，这就不就在浪费时间和资源嘛！
 
举个例子：
这就像有些父母，让自己的孩纸报N多的补习班，时间安排的非常满。
完全不管孩纸能不能接受，也不给孩纸消化的时间。
让孩纸长期处于超负荷状态，此时，孩纸再去学，是学不进去的。
而且前面所学的知识，也不牢靠。
又需要重新学，真是人间地狱啊！

流量控制的关键，就是要能够衡量接收方的处理速度。
怎么去衡量呢？

我们有一个明确的指标。
此处，我们就直接使用接收方 接收缓冲区 的 剩余空间大小，来衡量当前接收方的处理能力。
知识点：多线程基础篇中实战案例讲到了阻塞队列

---

 

六、拥塞控制

拥塞控制，也是滑动窗口的延伸，也是用来限制 滑动窗口 发送的速率。
拥塞控制，衡量的是 发送方到接收方，这整个链路之间，拥堵情况（处理能力）。
根据这个情况，我们来去决定发送的速率是多少。

举个例子来理解上图：谈恋爱
.>>刚开始谈恋爱的时候，两个人的感情几乎是呈直线上升的。（指数增长）
相处的时间久了之后，两个人的感情上升速度就没有刚才那么快了。（阈值）
处于一个平稳上升的状态。（线性增长）
但是也不是一直都在上升，两个人在一起，总会摩擦。（丢包）
一个不小心没处理好，就会分手，（回到初始窗口大小）
但两个人冷静之后，发现自己都有错，于是道歉和好。
感情又会进入直线上升的过程…
上面的图也就是这么个意思。

---

 

七、延时应答

延时应答 相当于是 流量控制的延伸。

流量控制 相当于是 踩了一下刹车，使发送方，发的不要太快。
延时应答，就想在这个基础上，能够尽量的再让窗口更大一些。

---

延时应答，具体延时多少呢？
1、数量限制：每隔N个包就应答一次；
2、时间限制：超过最大延迟时间就应答一次

---

 

八、捎带应答

捎带应答，又是延时应答的延伸。

---

 

九、面向字节流 =》粘包问题

不仅仅 TCP 存在粘包，其它的面向字节流的机制也存在。
比如：读文件。

细节拓展： 粘包，这两个字。

有的人可能会有所疑问：为什么要说这个？
这是因为有些人 读这个 粘 字，是 nian 第二声。
实际是读zhan 一声。
但是！无论你读哪一个发音，都没问题！
问题就出在：你要知道这两个发音，都是指的同一个问题。

假设：你只知道 粘包问题 的 粘 读 nian。
1、面试官问你：什么是 粘（zhan）包问题的时候，
你是一脸懵逼的状态。
2、不要和 面试官去争这个东西，不然offer会飞走。
他读什么。你读什么！

---

 

十、TCP的异常处理

---

 

1、进程终止

---

 

2、机器关机

按照操作系统约定的正常流程关机。

无论是关机，还是重启。
都是属于正常流程的关机，会让操作系统，杀死所有进程，然后在关机。
这就相当于回到 原因1【杀死进程】，
杀死进程，就会执行4次挥手。
4次挥手之后，才会真正进行关机

机器关机 的本质上 是 与 杀死进程 是一样的。
都是背刺的失败者！！

---

 

3、 机器掉电/网络断开

掉电，就是 台式电脑直接拔插头，电脑“嘭”一声，直接关机了。
这次才是真正完美的背刺！！！ 因为成功了！
操作系统在这种情况下，是不会有任何反应时间！更不会有任何的处理措施！
因为这个意外实在是太突然了！！！

---

 

总结

上述的 10个 TCP 特性，除了 粘包问题 之外。
其余九个都是为了：在保证可靠性的基础上，提升效率。

---

 

TCP vs UDP

1、什么时候使用 TCP？
对可靠性有一定的要求的场景。日常开发中的大多数情况，都是基于 TCP。
 
2、什么时候使用 UDP？
对可靠性要求不高，追求执行效率的场景。
比如：机房内部主机之间的通信，尤其是 分布式系统中。

由于机房内部的网络环境比较简单，网络带宽也高。
出现丢包的几率很小！并且想这种机房内部对于执行效率的要求也是蛮高的。
这个时候使用 UDP 更加合适！

---

 

经典面试题

基于UDP 如何实现可靠传输？（看起来是在考UDP，其实是在考TCP）
答案：就是“抄作业”！！！！
本质上就是在应用层基于 UDP 复刻 TCP的 机制。
保证可靠性 最重要的机制：确认应答 和 超时重传，你可以实现一下。
实现的同时，要确保这里面 引入 序号 和 确认序号。
再进一步确保可靠性：引入 连接管理（三次握手，四次挥手）
…
反正就是将上面的十个机制，都实现一下。
用代码去实现，也就是在应用层上实现。
 
这样的 UDP 与 TCP的区别就在于：
TCP 这十个机制都是操作系统内核代码实现好了的。
UDP 是我们手动敲出来的 十个机制。

传输层协议，只有 TCP 和 UDP吗？
像当下常见的 LOL,Dota2，吃鸡，王者荣耀…这些对抗性很高的游戏。
它们底层使用的 TCP，还是UDP？
答案：都不是！
既要保证可靠性，又要保证效率。
除了 TCP 和 UDP 之外，还有其它的一些协议。
有兴趣的，可以自行了解。

---

 

网络层

网络层最重要的协议就是 IP协议。

毕竟 TCP 和 IP 被称为 “冠名协议”。
我们现在学习的叫做 TCP/IP 协议栈。
所以肯定是 TCP 和 IP 是 最重要的协议。

IP协议的复杂程度，甚至比 TCP协议 还要高。
但是，我们不并作过多深究。

针对 IP 协议，主要完成的工作有两方面：
1、地址管理
2、路由选择

---

 

先来看一下IP协议的报头结构

---

 

IP协议主要完成两方面工作

1、地址管理

IP 地址 是一个 点分十进制 构成的数据。
对于这个IP地址来说，它这里面还可以进一步的来进行划分



IPv6 最关键的要点：使用了16个字节来表示IP地址。
虽然非常够用，但是受限于升级的成本。
以至于说：站在全世界的角度上来看，IPv4 还是站在一个主流地位。
因为，本篇博文仍然是以 IPv4为 主。

---

 

2、路由选择

路由选择，也就是规划路径。

当两个设备之间，要找出一条通道，能够完成传输的过程。
要想找出通道的前提是：要先认识路！

---

 

数据链路层

这一块，我会讲的很简短。
因为 数据链路层 已经是离我们程序 “非常远”了。
 
数据链路层主要的协议，叫做“以太网”。

像平时我们插的网线，就叫做“以太网线”。
至于 以太网的协议，我们不做过多讨论。

我们了解一下“以太”：
以太，本来是物理学上的概念。

就是说，以前人们对光的认识，不太深刻。
认为 光 也是一种波，必须要依靠介质才能传播。（类似声波）
后来，发现光也能在真空中传播。
当时的人们就蒙了。【光没有介质，也能传播的嘛？】
于是，就脑补出了一个介质：以太
认为“以太”，这一种介质在宇宙中无处不在。
光就是通过“以太”来进行传播的。
 
再往后，人们发现“以太”，这个说法并不靠谱。
这是因为两个人的存在：迈克尔逊 和 莫雷。
迈克尔逊 和 莫雷，这两个人做了一个实验。
证明了 光速在各个方向上，都是一致的。
【实验借助了地球的公转的速度，来进行验证。】
【根据 顺着公转 和 垂直公转，进行测量光的速度，发现都一样】
【如果存在介质，就是势必有些地方是分布不均匀的，这就会导致传播的速度是不一样】
 
可以说这个实验，就是间接的推翻了“以太”。
进一步就衍生出了 “狭义相对论”。
 
总之，以太 就是 人们的 一个臆想 / 一种假设。
但是这个概念，被保留了下来。
在我们的网络里，就把当前的数据链路层的协议称为“以太网”。

Ethernet, este protocolo no solo especifica el contenido de la capa de enlace de datos.
También se especifica el contenido de la capa física.
Ethernet es un protocolo que abarca dos capas.

Ethernet, la estructura de datos más central "marco de datos de Ethernet".

---

 

Resumir

En la posición actual, se ha discutido parte del contenido central de la red.
Entre ellos, TCP e IP son los protocolos más importantes que debemos dominar.
Porque nuestra pila de protocolos se llama pila de protocolos TCP/IP.
Especialmente TCP es muy importante.

---

 

Suplemento: acuerdo especial

---

 

DNS

DNS es un protocolo de capa de aplicación.
Su función: resolución de nombres de dominio.

---

 

NAPT

Este es el caso donde el número de puerto se repite como mencioné anteriormente, y su mecanismo de procesamiento es NAPT.

Esta asociación también la mantiene automáticamente el enrutador NAT.
Por ejemplo, en el caso de TCP, esta entrada se generará cuando se establezca la conexión;
después de que se desconecte la conexión, la entrada se eliminará