Comprensión de Http Https TCP/IP

1. Introducción a TCP Http Https UDP IP

TCP/IP

(Protocolo de control de transmisión/Protocolo de Internet, Protocolo de control de transmisión/Protocolo de Internet) se refiere a un conjunto de protocolos que puede realizar la transmisión de información entre múltiples redes diferentes. El protocolo TCP/IP no solo se refiere a los dos protocolos TCP e IP , sino que también se refiere a un grupo de protocolos compuesto por FTP , SMTP , TCP, UDP , IP y otros protocolos, simplemente porque en el protocolo TCP/IP, el protocolo TCP y el protocolo IP El más representativo, por eso se denomina protocolo TCP/IP.

tcp

(Protocolo de control de transmisión): el protocolo de control de transmisión es un protocolo de comunicación de capa de transporte basado en flujo de bytes, confiable y orientado a la conexión.

UDP

(Protocolo de datagramas de usuario): Protocolo de datagramas de usuario, alta eficiencia, poca confiabilidad, sin conexión

(Protocolo de Internet): Diseñado para que las redes de computadoras se comuniquen entre sí. Dirección IP = dirección de red + dirección de host o dirección IP = dirección de red + dirección de subred + dirección de host

HTTP

El Protocolo de transferencia de hipertexto (HTTP) es un protocolo simple de solicitud-respuesta

HTTPS

(Nombre completo: Protocolo de transferencia de hipertexto seguro [5]), es un canal HTTP destinado a la seguridad, basado en HTTP, garantiza la seguridad del proceso de transmisión mediante el cifrado de la transmisión y la autenticación de identidad [1]. HTTPS agrega SSL a la base de HTTP . La base de seguridad de HTTPS es SSL, por lo que los detalles del cifrado requieren SSL.

SSL

SSL (Secure Sockets Layer) y su sucesor Transport Layer Security (TLS) son un protocolo de seguridad que proporciona seguridad e integridad de datos para las comunicaciones de red. TLS y SSL cifran las conexiones de red entre la capa de transporte y la capa de aplicación.

¿Cuál es la diferencia entre HTTPS y HTTP?

La diferencia entre el protocolo http y el protocolo https: diferente seguridad de la información transmitida, diferentes métodos de conexión, diferentes puertos y diferentes métodos de solicitud de certificados.

1. La seguridad de la información transmitida es diferente

Protocolo http: es un protocolo de transferencia de hipertexto y la información se transmite en texto claro. Si un atacante intercepta los mensajes de transmisión entre el navegador web y el servidor del sitio web, puede leer directamente la información que contienen.

Protocolo https: es un protocolo de transmisión cifrado SSL/TLS seguro que cifra la comunicación entre el navegador y el servidor para garantizar la seguridad de la transmisión de datos.

2. Diferentes métodos de conexión

Protocolo http: la conexión http es muy simple y sin estado.

Protocolo https: es un protocolo de red creado mediante el protocolo SSL + HTTP que puede realizar transmisión cifrada y autenticación de identidad.

3. Diferentes puertos

Protocolo http: El puerto utilizado es el 80.

Protocolo https: El puerto utilizado es el 443.

4. Los métodos de solicitud de certificado son diferentes

Protocolo http: aplicación gratuita.

Protocolo https: debe solicitar un certificado de CA, generalmente hay pocos certificados gratuitos y debe pagar una tarifa.

2. Introducción detallada del protocolo TCP/IP

Primero, los datos TCP se encapsulan en un datagrama IP, como se muestra en la figura:

El encabezado IP tiene 20 bytes; el encabezado TCP suele tener 20 bytes.

Los detalles de distribución específicos de los datagramas IP se muestran en la siguiente figura: (La última parte de datos en la figura siguiente se refiere al mensaje TCP)

2.1 Introducción al encabezado IP

Los primeros 4 bytes (es decir, la primera línea):

Número de versión (Versión), 4 dígitos; se utiliza para identificar la versión del protocolo IP, IPv4 es 0100, IPv6 es 0110, que es binario 4 y 6

Tipo de servicio, 8 bits; se utiliza para identificar la prioridad de los paquetes IP, pero no se utiliza ahora

Longitud total, 16 bits; identifica la longitud total del datagrama IP, el máximo es: 2^16 -1 = 65535 bytes

Los segundos cuatro bytes (es decir, la segunda línea):

(1) Identificación, 16 bits; se utiliza para identificar datagramas IP. Si el datagrama IP debe enviarse en fragmentos debido al límite de longitud del segmento de datos del marco de la capa de enlace de datos (es decir, MTU, la unidad de transmisión máxima admitida), Entonces el identificador de datagrama IP de cada fragmento es coherente.

(2) Bandera, 3 bits, pero actualmente solo 2 bits son significativos; el bit más bajo es MF, MF = 1 significa que hay datagramas fragmentados más adelante, MF = 0 significa que el datagrama actual es el último datagrama. El siguiente bit más bajo es DF, DF=1 significa que la fragmentación no es posible, DF=0 significa que la fragmentación es posible.

(3) Desplazamiento de fragmento, 13 bits; representa la posición relativa de un determinado fragmento en los datos originales.

Los terceros cuatro bytes:

(1) Tiempo de vida (TTL), 8 bits; solía representar el tiempo máximo de supervivencia de los datagramas IP, pero ahora identifica la cantidad de enrutadores por los que pueden pasar los datagramas IP.

(2) Protocolo, 8 bits; representa el tipo de protocolo de la capa de transporte superior, 1 representa ICMP, 2 representa IGMP, 6 representa TCP y 17 representa UDP.

(3) Suma de verificación del encabezado, 16 bits; se utiliza para verificar la integridad de los datos. El método de cálculo es: primero establezca la posición de la suma de verificación en cero, luego sume cada complemento binario de 16 bits para obtener la suma de verificación y finalmente escriba la ubicación de la suma de verificación.

Los cuartos cuatro bytes: dirección IP de origen

El quinto cuatro bytes: dirección IP de destino.

2,2 bytes de encabezado TCP

Como se muestra abajo

A continuación se muestra una imagen más detallada de la estructura interna en el medio para ayudar con la comprensión. Esta imagen

Introducción al encabezado TCP

Los primeros 4 bytes (es decir, la primera línea):

(1) Puerto de origen, 16 bits/2 bytes; puerto de proceso de origen para enviar datos

(2) Puerto de destino, 16 bits/2 bytes; puerto de proceso para recibir datos

Los segundos 4 bytes y los terceros 4 bytes.

(1) Número de serie, 32 bits/4 bytes; representa la posición relativa del primer byte del segmento de datos TCP actual en todo el flujo de bytes;

(2) Número de confirmación, 32 bits / 4 bytes, representa el número de secuencia de datos que el extremo receptor espera recibir, que es el número de secuencia del último datagrama recibido + 1. Solo tiene efecto cuando el indicador ACK es 1.

Los cuartos 4 bytes:

(1) Longitud del encabezado: 4 bits; la longitud del encabezado del segmento del mensaje CP. Dado que la longitud del mensaje no es fija, el número decimal máximo que pueden representar 4 bits es 15, por lo que la longitud máxima del encabezado es 15 * 4 = 60 bytes.

(2) Reservado: 6 dígitos, no utilizados temporalmente

(3) 6 bits de bandera, 1 bit por cada bit de bandera;

这里插入一个常见疑问点：
备注：也有文章说标志位有8位，多了前两位CRW,ECE。这是为什么呢？
CWR：CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段，ECE 标志为 1 时，则通知对方已将拥塞窗口缩小；
ECE：若其值为 1 则会通知对方，从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1
因为多出来的两个标志位后来加的一个功能：显式拥塞通知（英语：Explicit Congestion Notification，简称ECN）是一个对网际协议和传输控制协议（TCP）的扩展，定义于 RFC 3168 （2001）。ECN允许拥塞控制的端对端通知而避免丢包。
虽然如今普及度已经很高了，但仍有些老旧的路由器和操作系统（比如：xp）是不支持的。（详细内容请转至 wiki百科显式拥塞通知，如果打不开则是被墙了）
在TCP连接上使用ECN也是可选的；当ECN被使用时，它必须在连接创建时通过SYN和SYN-ACK段中包含适当选项来协商。
所以他们只是讲了tcp中最基础的，所有设备都支持的那6个标志位
原文参考: https://www.likecs.com/show-203551574.html#sc=818.1818237304688

URG，为紧急序号，URG=1是紧急指针有效，告诉系统尽快发送此报文

ACK，为确认序号，ACK=1时确认号才有效；

PSH：PSH=1时，提示接收端应用程序立刻从TCP缓存中把数据读走，而不是等待缓冲区满

RST，重置连接。接收方收到RST=1时，表示对方要求立即重新建立连接。

SYN：SYN=1时，请求建立连接，，用于数据同步

FIN，为结束序号，FIN=1时，表示请求释放连接，用于发送端提出断开连接；

（4）窗口值，16位/2字节；指的是发送本报文的一方的接收窗口值的大小，告诉接收方当前自己可以接收数据量

第五个4字节

（1）校验和，16位；用于检验数据完整性。

（2）紧急指针，16位；只有当URG标识位为1时，紧急指针才有效。紧急指针的值与序号的相加值为紧急数据的最后一个字节位置。用于发送紧急数据。

最大字节总结：

IP数据报的最大长度=2^16-1=65535(字节)

TCP报文段的数据部分(也就是可发送的负载包大小)=IP数据报的最大长度-IP数据报的首部-TCP报文段的首部=65535-20-20=65495(字节)

一个TCP报文段（首部+tcp数据部分）的最大载荷是65515字节

2.3 UDP首部字节

如下如展示

UDP首部。只有8个字节：

16位/2字节的源端口号、16位/2字节的目的端口号：需要通信的两个进程之间的端口号，如果不需要接收方的回信，源端口号可为全0

16位/2字节的长度：UDP用户数据报的长度，最小值为8（仅有首部时）

16位/2字节的检验和：利用某种算法检测UDP用户数据报在传输过程中是否出错，如果有错，就丢弃

四、三次握手过程说明

三次握手的流程图：

三次握手的状态转换图，一定要熟记

三次握手过程：图中的标志位

第一次握手：SYN报文

客户端发起请求，SYN标志位为1，SEQ随机选择了一个初始序号client_isn，且存放在TCP报文字段的序号中。

第二次握手：SYNACK报文

当服务端收到报文后，会为其分配TCP缓存和变量（这里留一个思考，SYN 洪泛攻击，怎么办？会浪费资源的）然后服务端返回SYNACK报文到客户端，SYN标志位为1，确认号设置为client_isn + 1，并且选一个自己的初始序号server_isn，并放置在序号字段中

第三次握手：ACK报文

当收到服务器发来的SYNACK报文段后，客户端也需要给该连接分配缓存和变量，然后再次发送一个确认报文给服务端，其中，SYN标志位设置为0，将确认号设置为server_isn + 1，另外，此次报文可以携带负载数据：

五、为什么要三次握手而不是两次？

三次握手的目的是为了让双方验证各自的接收能力和发送能力。也就是说客户端要确认自己的发送和接收能力，同时也要确认服务端的发送和接收能力。服务端也一样，要确认自己的发送和接收能力，同时也要确认客户端的发送和接收能力

当第一次握手，A 发送SYN到B，B接收到了后，能确认什么呢？显然，B能确认A的发送能力和B的接收能力；

第二次握手，B发送SYNACK到A，A接收到后，能确认什么呢？A能确认B的发送能力和A自己的接收能力，此外，A收到了SYNACK，那么说明前面A发的SYN成功到达B的手中，所以也能确认A自己的发送能力和B的接收能力；至此，A已经确认了双方各自的发送能力和接收能力都是OK的，因此转为ESTABLISHED状态；

第三次握手，A发送ACK到B，B接收后，能确认什么呢？B能确认A的发送能力和B的接收能力。由于B能收到ACK说明前面发送的SYNACK已经成功被接受了，说明能确认A的接收能力和B的发送能力。

如果使用两次握手，就不能确认上述所说的四种能力，那么就会导致问题。

假定不采用第三次报文握手，那么只要B发出确认，新的连接就建立了。

假定一种异常情况，即A发出的SYN报文段并没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，却误以为是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据，但B却以为新的运输连接已经建立了，并一直等待A发来的数据。B的许多资源就这样白白浪费了。

六、四次挥手过程说明

挥手过程+状态图如下：

第一次挥手：FIN报文

客户主机发起连接释放的请求，设置FIN为1，当然，序号seq也会带上，这里假设为u；发送完毕后，客户端进入 FIN-WAIT-1 状态

第二次挥手：ACK报文

服务端接收到FIN 报文后，会返回一个ACK 报文回去，此时设置ACK为1，确认号为u + 1；表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。发送完毕后，服务器端进入 CLOSE-WAIT 状态，客户端接收到这个确认包之后，进入 FIN-WAIT-2 状态，等待服务器端关闭连接

第三次挥手：FINACK报文

服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1；发送完毕后，服务器端进入 LAST-ACK 状态，等待来自客户端的最后一个ACK。

第四次挥手：ACK报文

客户端接收到服务端传来的FIN 报文后，知道服务器已经准备好关闭了，发送一个确认包，并进入 TIME-WAIT状态，等待可能出现的要求重传的ACK 报文；服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。

七、为什么握手只要三次，挥手却要四次？

关键就在中间两步。

建立连接时，当服务器收到客户端的SYN 报文后，可以直接发送SYNACK 报文。其中ACK是用来应答的，SYN是用来同步的。

但是关闭连接时，当服务器收到FIN 报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK 报文，告诉客户端，“你发的FIN 报文我收到了”。只有等到服务器所有的报文都发送/接收完了，我才能发送FIN 报文，因此不能一起发送，需要四次握手。

HTTPS和HTTP的区别主要如下：

https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

八、拓展问题

8.1 两个TCP建立请求相互之间同时发起时会发生什么？建立几个连接？

答复：同时发起的两个请求最终只会建立一个连接

解析如下：

右箭头 (-->) ：从 A 发送到 B 的 TCP 报文段，且 B 接收到了；

左箭头 (<--) ：从 B 发送到 A 的 TCP 报文段，且 A 接收到了；

省略号 (…) ：TCP 报文段仍在网络中（delayed）；

丢失 ("XXX") ：TCP 报文段丢失或者被拒绝。

注释会放在括号中；

两个请求同时相互发起时，两个TCP均会经历如下状态的转换：

8.2 第三次握手失败了怎么办？

答复：总的来说，如果一个 ACK 报文丢失了，但它的下一个数据包没有丢失，那么连接正常，否则，连接会被重置。

解析：

ACK报文丢失导致第三次握手失败

当客户端收到服务端的SYNACK应答后，其状态变为ESTABLISHED，并会发送ACK包给服务端，准备发送数据了。如果此时ACK在网络中丢失（如上图所示），过了超时计时器后，那么服务端会重新发送SYNACK包，重传次数根据/proc/sys/net/ipv4/tcp_synack_retries来指定，默认是5次。如果重传指定次数到了后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。

问题就在这里，客户端已经认为连接建立，而服务端则可能处在SYN-RCVD或者CLOSED，接下来我们需要考虑这两种情况下服务端的应答：

服务端处于CLOSED，当接收到连接已经关闭的请求时，服务端会返回RST 报文，客户端接收到后就会关闭连接，如果需要的话则会重连，那么那就是另一个三次握手了。

服务端处于SYN-RCVD，此时如果接收到正常的ACK 报文，那么很好，连接恢复，继续传输数据；如果接收到写入数据等请求呢？注意了，此时写入数据等请求也是带着ACK 报文的，实际上也能恢复连接，使服务器恢复到ESTABLISHED状态，继续传输数据

更具体的介绍，跳转：https://blog.csdn.net/weixin_39969611/article/details/110464181

8.3 三次握手过程中可以携带数据吗？

第三次握手是可以携带数据的，而前两次不行。

8.4 客户端正在和服务端建立 TCP 连接，然而当服务器变 SYN-RCVD 后，此时一个旧的 SYN 报文又到达了，服务器会如何处理？

答复：服务端不能检测这个旧的SYN 报文是否正确，所以会正常返回SYNACK。而客户端收到会进行检测，发现是旧的报文，就发送RST 报文。

解析：

第三行就是旧的SYN 连接到达服务器时，第四行是服务器照常返回，第五行是客户端给服务端发送RST 报文，将服务端重置为LISTEN。

服务端在SYN_RECEIVED状态下，接收到旧的SYN 报文时是不能作出判断的，而是照常返回，当客户端接收到该报文后发现异常，才会发送RST 报文，重置连接。

8.5 知道SYN攻击吗？如何防范？这个问题感觉答复不是很清楚

所谓SYN 洪泛攻击，就是利用SYNACK 报文的时候，服务器会为客户端请求分配缓存，那么黑客（攻击者），就可以使用一批虚假的ip向服务器大量地发建立TCP 连接的请求，服务器为这些虚假ip分配了缓存后，处在SYN_RCVD状态，存放在半连接队列中；另外，服务器发送的请求又不可能得到回复（ip都是假的，能回复就有鬼了），只能不断地重发请求，直到达到设定的时间/次数后，才会关闭。

服务器不断为这些半开连接分配资源（但从未使用），导致服务器的连接资源被消耗殆尽，不过所幸，我们可以使用SYN Cookie进行有效地防御。

所谓的 SYN Cookie防御系统，与前面接收到 SYN 报文就分配缓存不同，此时暂不分配资源；同时利用 SYN 报文的源和目的地IP和端口，以及服务器存储的一个秘密数，使用它们进行散列，得到 server_isn，然后附着在 SYNACK 报文中发送给客户端，接下来就是对 ACK 报文进行判断，如果其返回的 ack字段正好等于 server_isn + 1，说明这是一个合法的 ACK，那么服务器才会为其生成一个具有套接字的全开的连接。

SYN Cookie 防御

当然这种方案也有一定缺点，最明显的就是服务器不保存连接的半开状态，就丧失了重发SYN-ACK消息的能力，这一方面会降低正常用户的连接成功率，另一方面会导致某些情况下正常通信的双方会对连接是否成功打开产生误解，如客户端发给服务端的第三次握手消息（ ACK）半路遗失，客户端认为连接成功了，服务端认为没收到 ACK，连接没成功，这种情况就需要上层应用采取策略特别处理了。

8.6 （ISN）是固定的吗？

不固定，client_isn是随机生成的，而server_isn则需要根据SYN 报文中的源、ip和端口，加上服务器本身的密码数进行相同的散列得到，显然这也不是固定的。

8.7 为什么 TIME_WAIT 状态需要经过 2MSL 才能转换到 CLOSE 状态？

第一，为了保证客户端发送的最后一个ACK 报文能够到达服务器。我们必须假设网络是不可靠的，ACK 报文可能丢失。如果服务端发出FIN 报文后没有收到ACK 报文，就会重发FIN 报文，此时处于TIME-WAIT状态的客户端就会重发ACK 报文。当然，客户端也不能无限久的等待这个可能存在的FIN 报文，因为如果服务端正常接收到了ACK 报文后是不会再发FIN 报文的。因此，客户端需要设置一个计时器，那么等待多久最合适呢？所谓的MSL（Maximum Segment Lifetime）指一个报文在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL时间后，客户端都没有再次收到FIN 报文，那么客户端推断ACK 报文已经被服务器成功接收，所以结束TCP 连接。