下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI（Open System Interconnect）模型中的位置：
image.png
Tcp 报文
image.png
TCP报文由首部和数据两部分组成。首部一般由20-60字节（Byte）构成，长度可变。其中前20B格式固定，后40B为可选。
因为，TCP报文还得传给下层网络层，封装成IP包，而一个IP包最大长度为65535，同时IP包首部也包含最少20B，所以一个IP包或TCP包可以包含的数据部分最大长度为65535-20-20=65495B。
序列号（seq）：表示发送数据的位置，字段长为32位。每发送一次数据，就累加一次该数据字节数的大小。
注意：序列号不会从0或1开始，而是在建立连接时由计算机生成的一个随机数作为其初始值，通过SYN包发送给接收端主机。然后再将每转发过去的字节数累加到初始值上表示数据的位置。
确认应答号（ask）：表示下一次应该收到的数据的序列号，字段长为32字节。发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。
状态位维护连接的状态。SYN发起连接，ACK回复，RST重新连接，FIN结束连接。
URG：紧急标志位，说明紧急指针有效；
ACK：确认标志位，多数情况下空，说明确认序号有效；
PSH：推标志位，置位时表示接收方应立即请求将报文交给应用层；
RST：复位标志，用于重建一个已经混乱的连接；
SYN：同步标志，该标志仅在三次握手建立TCP连接时有效
FIN：结束标志，带该标志位的数据包用于结束一个TCP会话。
Tcp 握手
image.png
tcp 需要三次握手是因为双方都需要确认对方能受到消息（链路是通的+对方还活着），也就是一个消息来回，那么最少也就需要三次。
客户端：你好，在吗
服务端：在的，你还在吗
客户端：在
开始传送数据。。。。
两次握手为什么不可以：(因为第二次握手的包可能会丢)
如果是两次握手，假设服务器给客户端在第二次握手时发送数据，数据从服务器发出，服务器认为连接已经建立，但在发送数据的过程中数据丢失，客户端认为连接没有建立，会进行重传。假设每次发送的数据一直在丢失，客户端一直SYN，服务器就会产生多个无效连接，占用资源，这个时候服务器可能会挂掉。这个现象就是我们听过的“SYN的洪水攻击”。
如果第三次握手的包丢了。。。
相信了解 tcp 协议的人，三次握手的过程肯定很了解了。第三次的 ack 包丢失就是说在 client 端接收到 syn + ack 之后，向 server 发送的 ack 包 由于各种原因 server 没有收到。这时 client, server 分别会进行怎样的处理呢？
Server 端
第三次的ACK在网络中丢失，那么Server 端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。
而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5.
如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接。
Client 端
在linux c 中，client 一般是通过 connect() 函数来连接服务器的，而connect()是在 TCP的三次握手的第二次握手完成后就成功返回值。也就是说 client 在接收到 SYN+ACK包，它的TCP连接状态就为 established （已连接），表示该连接已经建立。那么如果 第三次握手中的ACK包丢失的情况下，Client 向 server端发送数据，Server端将以 RST包响应，方能感知到Server的错误。
四次挥手：
image.png
第二张图主要说明白了ACKbit 和 ACKnum
需要四次挥手是因为因为TCP是全双工通信的，客户端想断开链接的时机是客户端的数据都发完了，但是这个时候不知道服务端还有没有数据，所以有四次：
通俗版：
客户端：断开吧
服务端：知道了
服务端：我也要断开了，拜拜
客户端：拜拜
略专业版：
step1：第一次挥手
首先，客户端发送一个FIN，用来关闭客户端到服务器的数据传送，然后等待服务器的确认。其中终止标志位FIN=1，序列号seq=u。
step2：第二次挥手
服务器收到这个FIN，它发送一个ACK，确认ack为收到的序号加一。
step3：第三次挥手
关闭服务器到客户端的连接，发送一个FIN给客户端。
step4：第四次挥手
客户端收到FIN后，并发回一个ACK报文确认，并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
为什么是4次挥手？
对于双向连接，2次握手只是断开单向连接，双向断开就需要4次挥手。第2、3次挥手不能合在一起，因为此时只能表明A不发送数据了，B可能还有数据要发送。
为什么A第4次挥手确认了ACK后，再TIME-WATI状态要等2MSL?
1、确认B收到最后的ACK。假如B没有收到ACK，会超时重传FIN，那么A在2MSL内就能重新收到FIN，于是再发送ACK。
有一种异常情况，B超过2MSL仍然没有收到ACK，即便重发FIN，A也不会再发送ACK了，而是发送RST，这样B就知道A已经离开。
2、防止已失效的报文段出现在下次连接中。A在发送最后一个ACK之后，再经过经过2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从而保证在关闭连接后不会有还在网络中滞留的报文段去骚扰B。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
四次挥手能不能变成三次挥手呢？
答案是可能的。
TCP是全双工通信，Cliet在自己已经不会在有新的数据要发送给Server后，可以发送FIN信号告知Server，这边已经终止Client到对端Server那边的数据传输。但是，这个时候对端Server可以继续往Client这边发送数据包。于是，两端数据传输的终止在时序上是独立并且可能会相隔比较长的时间，这个时候就必须最少需要2+2 = 4 次挥手来完全终止这个连接。但是，如果Server在收到Client的FIN包后，在也没数据需要发送给Client了，那么对Client的ACK包和Server自己的FIN包就可以合并成为一个包发送过去，这样四次挥手就可以变成三次了(似乎linux协议栈就是这样实现的)
第四次的挥手能不能去掉？设计成只用上面三次挥手完成关闭（自己想的问题）
不能，如果去掉最后一次，服务端发送Fin后就会关掉，如果客户端收到了这个fin，那可以正常关闭，但是，，，如果客户端没受到fin，就只能一直等待，无法关闭链接了，会一直以为可能还会有服务端发来的数据。
TCP的流量控制与拥塞控制的对比
https://blog.csdn.net/zhangdaisylove/article/details/47294897
https://blog.csdn.net/sicofield/article/details/9708383
Udp报文
image.png
Udp 、Tcp 对比
image.png
https:
会有七次握手，先tcp 3次 ，再有 tls 4次
image.png
TLS的握手阶段是发生在TCP握手之后。握手实际上是一种协商的过程，对协议所必需的一些参数进行协商。
SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥。
对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
注意https加密是在传输层
https报文在被包装成tcp报文的时候完成加密的过程，无论是https的header域也好，body域也罢都是会被加密的。
从输入url到看到内容，发生了什么：
https://fex.baidu.com/blog/2014/05/what-happen/
参考：http://blog.jobbole.com/114633/
https://cloud.tencent.com/developer/article/1004327
https://blog.csdn.net/zqz_zqz/article/details/79548381
https://blog.csdn.net/u012319493/article/details/82831166
https:
网友评论