Http Https TCP/IP understanding

1. Introduction to TCP Http Https UDP IP

TCP/IP

(Transmission Control Protocol/Internet Protocol, Transmission Control Protocol/Internet Protocol) refers to a protocol suite that can realize information transmission between multiple different networks. The TCP/IP protocol not only refers to the two protocols TCP and IP , but also refers to a protocol cluster composed of FTP , SMTP , TCP, UDP , IP and other protocols, just because in the TCP/IP protocol, the TCP protocol and the IP protocol The most representative, so it is called TCP/IP protocol.

TCP

(Transmission Control Protocol): Transmission Control Protocol is a connection-oriented, reliable, byte stream-based transport layer communication protocol

UDP

(User Datagram Protocol): User Datagram Protocol, high efficiency, poor reliability, connectionless

(Internet Protocol): Designed for computer networks to communicate with each other. IP address = network address + host address or IP address = network address + subnet address + host address

HTTP

Hyper Text Transfer Protocol (HTTP) is a simple request-response protocol

HTTPS

(Full name: Hypertext Transfer Protocol Secure [5] ), is an HTTP channel aimed at security. Based on HTTP, it ensures the security of the transmission process through transmission encryption and identity authentication [1] . HTTPS adds SSL to the foundation of HTTP . The security foundation of HTTPS is SSL, so the details of encryption require SSL.

SSL

SSL (Secure Sockets Layer) and its successor Transport Layer Security (TLS) are a security protocol that provides security and data integrity for network communications. TLS and SSL encrypt network connections between the transport layer and the application layer.

What is the difference between HTTPS and HTTP?

The difference between http protocol and https protocol: different security of transmitted information, different connection methods, different ports, and different certificate application methods.

1. The security of transmitted information is different

http protocol: It is a hypertext transfer protocol, and information is transmitted in clear text. If an attacker intercepts the transmission messages between the web browser and the website server, he can directly read the information in them.

https protocol: It is a secure SSL/TLS encrypted transmission protocol that encrypts the communication between the browser and the server to ensure the security of data transmission.

2. Different connection methods

http protocol: http connection is very simple and stateless.

https protocol: It is a network protocol built by SSL+HTTP protocol that can perform encrypted transmission and identity authentication.

3. Different ports

http protocol: The port used is 80.

https protocol: The port used is 443.

4. Certificate application methods are different

http protocol: free to apply.

https protocol: You need to apply for a certificate from CA. Generally, there are few free certificates and you need to pay a fee.

2. Detailed introduction of TCP/IP protocol

First, TCP data is encapsulated in an IP datagram, as shown in the figure:

The IP header is 20 bytes; the TCP header is usually 20 bytes.

The specific distribution details of IP datagrams are shown in the figure below: (The last data part in the figure below refers to the Tcp message)

2.1 Introduction to IP header

The first 4 bytes (that is, the first line):

Version number (Version), 4 digits; used to identify the IP protocol version, IPv4 is 0100, IPv6 is 0110, which is binary 4 and 6

Type Of Service, 8 bits; used to identify the priority of IP packets, but is not used now

Total Length, 16 bits; identifies the total length of the IP datagram, the maximum is: 2^16 -1 = 65535 bytes

The second four bytes (that is, the second line):

(1) Identification, 16 bits; used to identify IP datagrams. If the IP datagram needs to be sent in fragments due to the length limit of the data link layer frame data segment (that is, MTU, the maximum supported transmission unit), Then the IP datagram identifier of each fragment is consistent.

(2) Flag, 3 bits, but currently only 2 bits are meaningful; the lowest bit is MF, MF=1 means there are fragmented datagrams later, MF=0 means the current datagram is the last datagram . The next lowest bit is DF, DF=1 means fragmentation is not possible, DF=0 means fragmentation is possible.

(3) Fragment Offset, 13 bits; represents the relative position of a certain fragment in the original data.

The third four bytes:

(1) Time to Live (TTL), 8 bits; it used to represent the maximum survival time of IP datagrams, but now identifies the number of routers that IP datagrams can pass through.

(2) Protocol, 8 bits; represents the type of upper transport layer protocol, 1 represents ICMP, 2 represents IGMP, 6 represents TCP, and 17 represents UDP.

(3) Header Checksum, 16 bits; used to verify data integrity. The calculation method is: first set the checksum position to zero, then sum up each 16-bit binary complement to get the checksum, and finally Write checksum location.

The fourth four bytes: source IP address

The fifth four-byte: destination IP address.

2.2 Bytes of TCP header

As shown below

A more detailed picture of the internal structure in the middle is as follows to help with understanding. This picture

Introduction to TCP header

The first 4 bytes (that is, the first line):

(1) Source port, 16 bits/2 bytes; source process port for sending data

(2) Destination port, 16 bits/2 bytes; process port for receiving data

The second 4 bytes and the third 4 bytes

(1) Serial number, 32 bits/4 bytes; represents the relative position of the first byte of the current TCP data segment in the entire byte stream;

(2) Confirmation number, 32 bits/4 bytes; represents the data sequence number that the receiving end hopes to receive, which is the sequence number of the last datagram received + 1. It only takes effect when the ACK flag is 1.

The fourth 4 bytes:

(1) Header length: 4 bits; the header length of the CP message segment. Since the length of the message is not fixed, the maximum decimal number that 4 bits can represent is 15, so the maximum header length is 15*4=60 bytes.

(2) Reserved: 6 digits, temporarily unused

(3) 6 flag bits, 1 bit for each flag bit;

这里插入一个常见疑问点：
备注：也有文章说标志位有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 连接。