Http Https TCP/IP理解

一、 TCP Http Https UDP IP 介绍

TCP/IP

（Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议）是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是TCP 和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇，只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。

TCP

(Transmission Control Protocol):传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议

UDP

(User Datagram Protocol):用户数据报协议，效率高，可靠性差，无连接的

(Internet Protocol):为计算机网络相互连接进行通信而设计.IP地址=网络地址+主机地址或 IP地址=网络地址+子网地址+主机地址

HTTP

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议

HTTPS

（全称：Hypertext Transfer Protocol Secure [5] ），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 [1] 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

SSL

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

HTTPS和HTTP有什么区别?

http协议和https协议的区别：传输信息安全性不同、连接方式不同、端口不同、证书专申请方式不同.

1.传输信息安全性不同

http协议：是超文本传输协议，信息是明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。

https协议：是具有安全性的ssl/tls加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。

2.连接方式不同

http协议：http的连接很简单，是无状态的。

https协议：是由SSL＋HTTP协议构建的可进行加密传输、身份认证的网络协议。

3.端口不同

http协议：使用的端口是80。

https协议：使用的端口是443．

4.证书申请方式不同

http协议：免费申请。

https协议：需要到ca申请证书，一般免费证书很少，需要交费。

二、TCP/IP协议具体介绍

首先TCP数据是被封装在一个IP数据报中，如图所示：

IP首部是20个字节；TCP首部通常也是20个字节。

IP数据报的具体分配细节如下图所示：（下图中最后的数据部分指的就是Tcp报文）

2.1 IP首部介绍

第一个4字节（也就是第一行）：

版本号（Version），4位；用于标识IP协议版本，IPv4是0100，IPv6是0110，也就是二进制的4和6

服务类型（Type Of Service），8位；用于标识IP包的优先级，但现在并未使用

总长度（Total Length），16位；标识IP数据报的总长度，最大为：2^16 -1 = 65535字节

第二个四字节（也就是第二行）：

（1）标识（Identification），16位；用于标识IP数据报，如果因为数据链路层帧数据段长度限制（也就是MTU，支持的最大传输单元），IP数据报需要进行分片发送，则每个分片的IP数据报标识都是一致的。

（2）标识（Flag），3位，但目前只有2位有意义；最低位为MF，MF=1代表后面还有分片的数据报，MF=0代表当前数据报已是最后的数据报。次低位为DF，DF=1代表不能分片，DF=0代表可以分片。

（3）片偏移（Fragment Offset），13位；代表某个分片在原始数据中的相对位置。

第三个四字节：

（1）生存时间（TTL），8位；以前代表IP数据报最大的生存时间，现在标识IP数据报可以经过的路由器数。

（2）协议（Protocol），8位；代表上层传输层协议的类型，1代表ICMP，2代表IGMP，6代表TCP，17代表UDP。

（3）校验和（Header Checksum），16位；用于验证数据完整性，计算方法为，首先将校验和位置零，然后将每16位二进制反码求和即为校验和，最后写入校验和位置。

第四个四字节：源IP地址

第五个四字节：目的IP地址。

2.2 TCP首部的字节

如下图展示

中间内部结构更详细的一张图，如下，帮助理解。此图

TCP首部介绍

第一个4字节（也就是第一行）：

（1）源端口，16位/2字节；发送数据的源进程端口

（2）目的端口，16位/2字节；接收数据的进程端口

第二个4字节与第三个4字节

（1）序号，32位/4字节；代表当前TCP数据段第一个字节占整个字节流的相对位置；

（2）确认号，32位/4字节；代表接收端希望接收的数据序号，为上次接收到数据报的序号+1，当ACK标志位为1时才生效。

第四个4字节：

（1）首部长度：4位；CP报文段的首部长度，由于报文的长度不固定，4bit能表示的最大十进制数字是15，因此首部长度最大是15*4=60字节。

（2）保留：6位，暂时未用

（3）6个标志位，每个标志位1位；

这里插入一个常见疑问点：
备注：也有文章说标志位有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 状态，等待服务器端关闭连接

第三次挥手：FIN报文

服务器端准备好关闭连接时，向客户端发送结束连接请求，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 连接。