034* （网络七层架构）（TCP三次握手和四次挥手）（TCP、UDP、SOCKET、http、Https）（单向认证和双向认证）（http状态码） - 风zk

时间：2024-03-01 08:49:43

034* （网络七层架构）（TCP三次握手和四次挥手）（TCP、UDP、SOCKET、http、Https）（单向认证和双向认证）（http状态码）

 一:网络7层协议和主要协议

OSI 模型 主要协议 单位 作用
应用层 HTTP、FTP、Telnet、STMP、POP3、IMAP等 数据流 为应用程序提供访问网络服务的接口
表示层 CSS GIF HTML JSON XML GIF 数据流 数据格式转换、加密、压缩
会话层 FTP SSH TLS HTTP(S) SQL 数据流 建立会话
传输层 TCP UDP 数据段 建立端口到端口的通信。
网络层 IP(IPV4、IPV6) ICMP 数据包

进行逻辑地址寻址，实现不同网络之间的路径选择，

确保数据包及时传送。
数据链路层 ARP、RARP 帧

建立相邻结点之间的数据链路，通过差错控制

提供数据帧（Frame）在信道上无差错的传送
物理层 V.35、EIA/TIA-232 比特流 为数据终端设备提供传送数据的通路

 

 

 

 

 

 

 

 

二：TCP三次握手和四次挥手

1：TCP报文首部首部的格式

1：序号seq（Sequence Number）：占4个字节，用来标识从TCP发端向TCP收端发送的数据字节流（tcp传输的每一个字节都按顺序编号），它表示在这个报文段中的的第一个数据字节在数据流中的序号。主要用来解决网络报乱序的问题。

2：确认号ack（Acknowledgment Number）：占4个字节，确认序列号包含发送确认的一端所期望收到的下一个序号，因此，确认序号应当是上次已成功收到数据字节序号加1。不过，只有当标志位中的ACK标志为1时该确认序列号的字段才有效。主要用来解决不丢包的问题（确认序号减去上次收到的序号等于本段收到的报文的长度）。ack=上次发送的seq+1

3：确认ACK：标志位。TCP应答号将会包含在TCP数据包中，有两个取值：0和1，为1的时候表示应答域有效，反之为0。也规定连接建立后所有发送的报文的ACK必须为1。

4：同步SYN：表示同步序号，用来建立连接，SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被响应的时候，SYN=1，ACK=1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手。

5：终止FIN： 表示发送端已经达到数据末尾，将释放一个连接，FIN = 1， 表示报文段的发送方的数据已经发送完成，请求释放连接。

2：三次握手

1.第一次握手

客户端向服务端发送连接请求报文段。该报文段的头部中同步SYN=1，确认ACK=0，同时选择一个初始序号seq=x。请求发送后，客户端便进入SYN-SENT（请求连接）状态。

  • SYN=1，ACK=0表示该报文段为连接请求报文
  • seq=x为本次TCP通信的字节流的初始序号
  • TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号

2.第二次握手

服务端收到连接请求报文段后，如果同意连接，会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。发送完应答后服务端进入SYN-RCVD（同步收到）状态。

  • SYN=1，ACK=1表示该报文段为连接同意的应答报文
  • seq=y表示服务端作为发送者时，发送字节流中的第一个字节序号
  • ack=x+1表示服务端希望客户端发送的下一个数据报初始序号是从x+1开始

3.第三次握手

客户端收到服务端连接同意的应答后，还会向服务端发送一个确认报文段，表示：服务端发来的连接同意应答，已经成功收到。该报文段的头部为：

ACK=1，seq=x+1，ack=y+1。

客户端发完这个报文段后便进入ESTABLISHE（链接成功）D状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接的建立完成

3：四次挥手

1.第一次挥手

客户端数据发送完成，则它向服务端发送连接释放请求。该请求只有报文头，头中携带的主要参数为：FIN=1，seq=u。此时，客户端将进入FIN-WAIT-1状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

  • FIN=1表示该报文段是一个连接释放请求
  • seq=u，u-1是客户端向服务端发送的最后一个字节的序号

2.第二次挥手

服务器收到客户端连接释放报文，通知相应的高层应用进程，告诉它客户端向服务器这个方向的连接已经释放了。

此时服务端进入了CLOSE-WAIT（关闭等待）状态，并向客户端发出连接释放的应答，其报文头包含：

ACK=1，ack=u+1，并且带上自己的序列号seq=v。

  • ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答
  • seq=v，v是服务端释放应答报文段第一个字节序号
  • ack=u+1表示希望收到从第u+1个字节开始的报文段，并且已经成功接收了前u个字节

客户端收到该应答后，进入FIN-WAIT-2状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

第二次挥手完成后，

客户端到服务端方向的连接已经释放，服务端不会再接收客户端的数据，客户端也没有数据要发送了。

但服务端到客户端方向的连接仍然存在，服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3.第三次挥手

服务端将最后的数据发送完毕后，就向客户端发送连接释放报文，其报文头包含：

FIN=1，

ack=u+1，

由于在CLOS-WAIT状态，服务端很可能又发送了一些数据，

假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

4.第四次挥手

客户端收到服务器的连接释放报文后，向服务端发出确认应答，报文头：ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。

该状态会持续2MSL（最长报文段寿命）时间，这个期间TCP连接还未释放，若该时间段内没有服务端的重发请求的话，客户端就进入CLOSED状态，撤销TCP链接。

服务端只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCP后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

4：为什么连接的时候是三次握手，关闭的时候却是四次握手？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

三：TCP、UDP、SOCKET、HTTP

TCP为传输控制层协议，为面向连接、可靠的、点到点的通信；
UDP为用户数据报协议，非连接的不可靠的点到多点的通信；
TCP侧重可靠传输，UDP侧重快速传输。
 
1：TCP是面向连接的一种传输控制协议。
TCP连接之后，客户端和服务器可以互相发送和接收消息，在客户端或者服务器没有主动断开之前，连接一直存在，故称为长连接。
特点：连接有耗时，传输数据无大小限制，准确可靠，先发先至。
 
2：UDP是无连接的用户数据报协议。
所谓的无连接就是在传输数据之前不需要交换信息，没有握手建立连接的过程，只需要直接将对应的数据发送到指定的地址和端口就行。
故UDP的特点是不稳定，速度快，可广播，一般数据包限定64KB之内，先发未必先至。
 
HTTP协议是基于TCP连接的，是应用层协议，主要解决如何包装数据。Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。
 
3：socket: 长连接，客户端跟服务器端直接使用Socket进行连接，没有规定连接后断开，因此客户端和服务器段保持连接通道，双方可以主动发送数据，一般多用于游戏.Socket默认连接超时时间是30秒，默认大小是8K（理解为一个数据包大小）。推送就是socket长链接。
 
4：HTTP：超文本传输协议（Hypertext Transfer Protocol）：短连接，客户端向服务器发送一次请求，服务器响应后连接断开，节省资源。服务器不能主动给客户端响应（除非采用HTTP长连接技术），
 
5：HTTPS：安全超文本传输协议（Secure Hypertext Transfer Protocol），它是一个安全通信通道，基于HTTP开发，用于客户计算机和服务器之间交换信息，使用安全套结字层（SSI）进行信息交换，即HTTP的安全版。

6：建立socket链接至少需要一对套接字，其中一个运行与客户端，请一个运行于服务端，连接过程主要分为3步：服务器监听、客户端请求和连接确认。
1、服务器监听：处于等待链接的状态，实时监控网络状态等待客户端的连接请求。
2、客服端请求：客户端提出连接请求必须要首先面熟要连接服务器的socket，指出地址和端口号然后想服务器提出连接请求。
3、连接确认：当服务器接收到客户端的请求时，就会响应请求，建立一个新的线程，把服务端的socket描述发给客户端，一旦客户端确认，双方建立连接。而服务器端继续保持监听状态，接收其他客户端套接字的连接请求。

 7：HTTPS链接
1：HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，
TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。
 

1：具体做法是：发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。 

2：所有字段：按字符顺序排列，hash算法，信息摘要，拼接成一个新的字段。

2：证书生成

1）申请认证：服务器需自己生成公钥私钥对pub_svr & pri_svr，同时根据 pub_svr 生成请求文件 csr, 提交给 CA 机构，csr 中含有公钥、组织信息、个人信息(域名)等信息。(图一中 server.req 就是 csr 请求文件)

2）审核信息：CA 机构通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。

3）签发证书：如信息审核通过，CA 机构会向申请者签发认证文件-证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。（图一中生成 server.crt）

4）返回证书：client 如果请求验证服务器，服务器需返回证书文件。（图一中 handshake 传回 server.crt）

5）client验证证书：client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
客户端会内置信任 CA 的证书信息(包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。(图一中check 可选，我们可以选择不验证服务器证书的有效性)

6）秘钥协商：验证通过后，Server 和 Client 将进行秘钥协商。接下来 Serve r和 Client 会采用对称秘钥加密。(对称加密时间性能优)（图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程）

7）数据传输：SSL Server 和 SSL Client 采用对称秘钥加密解密数据。

3：HTTPS采用对称加密和非对称加密两者并用的混合加密机制

1.Client发起一个HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”

四：单向认证和双向认证

1：单向认证流程中，服务器端保存着公钥证书和私钥两个文件，整个握手过程如下：

 

  1. 客户端发起建立HTTPS连接请求，将SSL协议版本的信息发送给服务器端；
  2. 服务器端将本机的公钥证书（server.crt）发送给客户端；
  3. 客户端读取公钥证书(server.crt)，取出了服务端公钥；
  4. 客户端生成一个随机数（密钥R），用刚才得到的服务器公钥去加密这个随机数形成密文，发送给服务端；
  5. 服务端用自己的私钥(server.key)去解密这个密文，得到了密钥R
  6. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。

2： 双向认证流程

  1. 客户端发起建立HTTPS连接请求，将SSL协议版本的信息发送给服务端；
  2. 服务器端将本机的公钥证书(server.crt)发送给客户端；
  3. 客户端读取公钥证书(server.crt)，取出了服务端公钥；
  4. 客户端将客户端公钥证书(client.crt)发送给服务器端；
  5. 服务器端使用根证书(root.crt)解密客户端公钥证书，拿到客户端公钥；
  6. 客户端发送自己支持的加密方案给服务器端；
  7. 服务器端根据自己和客户端的能力，选择一个双方都能接受的加密方案，使用客户端的公钥加密8. 后发送给客户端；
  8. 客户端使用自己的私钥解密加密方案，生成一个随机数R，使用服务器公钥加密后传给服务器端；
  9. 服务端用自己的私钥去解密这个密文，得到了密钥R
  10. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。

五：Http状态码

HTTP状态码(HTTP Status Code)

200 请求被正常处理

204 请求被受理但没有资源可以返回
206 客户端只是请求资源的一部分，服务器只对请求的资源执行GET方法，相应报文中通过Content-Range 指定范围的资源
301 永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
302 临时重定向临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）
303 与302状态码有相似的功能，只是它希望客户端应使用GET方法 临时重定向定向获取请求的资源
304 发送附带条件的请求时，条件不满足时返回，与重定向无关
307 临时重定向，与302类似，只是强制要求使用post方法
400 请求报告语法有误，服务器无法识别
401 请求需要认证
403 请求的对应的资源禁止被访问
404 服务器无法找到对应的资源
410（已删除）如果请求的资源已永久删除，服务器就会返回此响应。
500 服务器内部错误
503 服务器正忙
502（错误网关）服务器作为网关或代理，从上游服务器收到无效响应。
504（网关超时）服务器作为网关或代理，但是没有及时从上游服务器收到请求。

六：证书格式：

pem（把二进制数据用base64编码）->crt(二进制数据)->(der[公钥、证书]、p12[私钥])

crt和pem中有公钥和私钥他们是base64编码的文件。 

1：Privacy Enhanced Mail，一般为文本格式，以 -----BEGIN... 开头，以 -----END... 结尾。中间的内容是 BASE64 编码。这种格式可以保存证书和私钥。

—–BEGIN CERTIFICATE—–
MIIE9jCCA96gAwIBAgIQVXD9d9wgivhJM//a3VIcDjANBgkqhkiG9w0BAQUFADBy
—–END CERTIFICATE—–
2：.CRT，可以是二进制格式，可以是文本格式

七：其他问题

1：get和post的区别

1：用途不同：

  • GET：一般用于请求
  • POST：一般用于表单提交，提交数据

2：安全性不同

  • GET：不安全，GET的请求是明文传输，简而言之就是你的请求信息是直接跟在URL后面的，用户都看得到
  • POST：安全，POST方法会将信息放在请求体body中，用户是看不到的

3：数据长度限制

  • GET：对传输的数据长度有限制
  • POST：对数据长度没有限制，因为数据都是放在消息体中的

4：：是否会自动缓存

  • GET：GET请求会被浏览器自动缓存
  • POST：缓存需要手动设置

5：编码类型

  • get：application/x-www-form-urlencoded
  • post：application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。

　　

2：http请求有哪些部分

请求报文包含：请求行、请求头、请求体四部分组成。
响应报文包含：状态行、响应头、响应体三部分组成。

 

3：请求头有那些参数

　　   Accept：浏览器可接受的MIME类型；

         Accept-Charset：浏览器可接受的字符集；

         Accept-Encoding：浏览器能够进行解码的数据编码方式，

         Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到；

         Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中；

         Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小；

         Content-Length：表示请求消息正文的长度；

         Cookie：这是最重要的请求头信息之一；

         Host：初始URL中的主机和端口；

         If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答；

         Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。

         User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用；

 

4：Ping是什么协议？

　　　　Ping命令用ICMP是“Internet Control Message Ptotocol”（Internet控制消息协议）的缩写，用于IP主机，路由器之间传递消息。

　　　　控制消息是指网络通不通，主机是否可达，路由器是否可用等网络本身的消息，这些控制消息并不传输用户数据。

 

5：知道MTU吗？

　　Maximum Transmission Unit，缩写MTU，中文名是：最大传输单元。

为什么是1500？其实一个标准的以太网数据帧大小是：1518，头信息有14字节，尾部校验和FCS占了4字节，所以真正留给上层协议传输数据的大小就是：1518 - 14 - 4 = 1500，那么，1518这个值又是从哪里来的呢？

 

6：TCP头部多长，IP头部有多长？

TCP头部20 bytes

IP头部20 bytes

 

7：Http2.0如1.x的区别

1：HTTP1.0和HTTP1.1的一些区别

长连接，缓存策略，

2：HTTP2.0和HTTP1.X的区别

  • 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
  • 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
  • header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
  • 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

8：TCP 流量控制

 

双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。

 

如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。 

 

对发送方发送速率的控制，我们称之为流量控制。

 

 

9：比较 Cookie 和 Session 

cookie 和session 的区别：

  • 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
  • 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
  • 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
  • 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
  • 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

cookie 和session 的联系：

session是通过cookie来工作的
session和cookie之间是通过$_COOKIE[\'PHPSESSID\']来联系的，通过$_COOKIE[\'PHPSESSID\']可以知道session的id，从而获取到其他的信息。
在购物网站中通常将用户加入购物车的商品联通session_id记录到数据库中，当用户再次访问是，
通过sessionid就可以查找到用户上次加入购物车的商品。因为sessionid是唯一的，记录到数据库中就可以根据这个查找了。

10：断点续传怎么实现？需要设置什么？

会用到HTTP首部字段Range来指定资源的byte范围