简述 TCP 和 UDP 的区别

TCP 和 UDP 是 OSI 网络模型中的运输层的协议，TCP 提供可靠的通信传输，而 UDP 则常被用于让广播和细节控制控制交给应用的通信传输
区别：

• TCP 面向连接，UDP 面向非连接及发送数据前不需要 建立连接
• TCP 提供可靠的服务（数据传输），而 UDP 无法保证
• TCP 面向字节流，UDP 面向报文
• TCP 数据传输慢，UDP 数据传输快

端口号及对应的服务

• 21 FTP 文件传输协议
• 22 SSH
• 23 Telnet 远程登陆服务
• 25 SMTP 简单邮件传输协议
• 53 DNS 域名服务器
• 80 HTTP 超文本传输协议
• 443 HTTPS
• 1080 Sockets
• 1521 Oracle 数据库
• 3306 Mysql 服务

TCP 三次握手

在 TCP/IP 协议中，TCP 协议提供可靠的连接服务，连接是通过三次握手进行初始化的，三次握手的目的是同步连接双方的序列号和确认双方的发送和接收信息的能力

• 第一次握手：客户端发送 syn 标记的报文，发送完成客户端进入 SYN_SEND 状态
• 第二次握手：服务端接收到 syn 报文后，会返回给客户端确认包(ACK)应答，表示已确认收到信息，同时还会发送一个 SYN 包回去，确认客户端是否能收到，发送完成服务端进入 SYN_RCVD 状态
• 第三次握手：客户端接收到 SYN 报文 后，再次发送确认包 ack，表示确认收到服务端的包，服务端发送完毕，进入 ESTABLISHED 状态，服务端接收到这个包，也进入 ESTABLISHED 状态，TCP 握手结束

为什么是三次握手？

三次握手的主要目的是确认双方的接收和发送能力是否正常

第一次：客户端发送给服务端，服务端收到，服务端就知道客户端发送能力和服务端接受能力都 ok
第二次：服务端发送给客户端，客户端收到，客户端直到服务端接收、发送和客户端接收、发送都 ok，不过此时服务端不知道客户端接收和服务端发送是否正常
第三次：客户端发送给服务端，服务端收到，由此客户端和服务端的发送接收能力都正常

不是二次握手问题：无法确认客户端的接受能力，比如双发发送消息，但是由于网络原因导致重传了，而我现在已经断开连接了，而你并不需要确认我能不能接收到你的信息，就自动认为两次握手就自动连接了，但其实现在我已经断开连接了，会造成资源上的浪费

四次挥手

建立一个 TCP 连接需要三次握手，而终止一个连接要四次挥手，这是由 TCP 的半关闭造成的，所谓的半关闭，其实是 TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
TCP 连接的拆除需要发送四个包，客户端或服务端均可主动发起挥手动作
刚开始双方都处于 ESTABLISHED 状态，假如客户端发起关闭请求，四次挥手过程如下：
第一次挥手：客户端发送一个 FIN 报文，告诉服务器需要关闭连接，表示自己不用发送数据了，但是还可以接收数据，发送完成后，客户端进入 FIN_WAI_1 状态
第二次挥手：服务端收到 FIN 后，会发送一个 ACK 的确认包，告诉客户端接收到关闭的请求，但还没有准备好。发送完成后，服务端进入 CLOSE_WAIT 状态，客户端接收到这个包后，进入 FIN_WAIT2 状态，等待服务器关闭连接
第三次：服务端准备好关闭连接时，发送 FIN 标记的包，告诉客户端准备关闭了，发送完成后，服务端进入 LAST_ACK 状态，等待客户端确认
第四次：客户端收到服务端的关闭请求，再次发送 ACK 标记的确认包，进入 TIME_WAIT 状态，等待服务端可能请求重传的 ACK 包。服务端接收到 ACK 包后，关闭连接，进入 CLOSED 状态，客户端在等待固定时间（两个最长报文段寿命），没有接收到服务端的 ACK 包，认为服务器已关闭连接，自己也关闭连接，进入 CLOSED 状态

为什么需要四次挥手

当服务端接收到客户端的 SYN 连接请求报文后，可以直接发送 SYN 和 ACK 报文（ACK 是用来应答，SYN 用来同步），但当关闭连接时，服务端收到 FIN 报文时，并不会立即返回 FIN，必须等到服务端所有报文都发送完毕，才能发 FIN，所以只能先回复 ACK 报文，告诉客户端已经收到你的 FIN 报文了，只有等我服务端所有的报文都发送完了，才能发送 FIN 报文，因此不能一起发送

四次挥手等待 2MSL

TIME_WAIT 状态也称为 2MSL 等待状态，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃

两个理由：

• 保证客户端发送的最后一个 ACK 报文段能够到达客户端
  这个 ACK 报文段有可能丢失，使得处于 LAST-ACK 状态的 B 收不到对已发送的 FIN+ACK 报文段的确认，服务端超时重传 FIN+ACK 报文段，而客户端能在 2MSL 时间内收到这个重传的 FIN+ACK 报文段，接着客户端重传一次确认，重新启动 2MSL 计时器，最后客户端和服务端都进入到 CLOSED 状态，若客户端在 TIME-WAIT 状态不等待一段时间，而是发送完 ACK 报文段后立即释放连接，则无法收到服务端重传的 FIN+ACK 报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到 CLOSED 状态。
• 防止“已失效的连接请求报文段“出现在本连接中
  客户端在发送完最后一个 ACK 报文段后，再经过 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

半连接队列和 SYN Flood 攻击关系

三次握手前，服务端状态由 CLOSED 变为 LISTEN，同时在内部创建两个队列：半连接队列和全连接队列

• 半连接队列
  SYN 队列，当客户端发送 SYN 到服务端，服务端收到后回复 ACK 和 SYN，状态由 LISTEN 变为 SYN_RCVD，此时这个队列被推入到 SYN 队列

• 全连接队列
  ACCEPT 队列，当客户端返回 ACK，服务端接收后，三次握手完成，被推入另一个 TCP 维护的队列，全连接队列

• SYN Flood 攻击原理
  属于典型的 Dos/DDos 攻击，攻击原理是：短时间内伪造大量不存在的 IP 地址，向都无端疯狂发送 SYN，此时服务端处理大量 SYN 并返回对应的 ACK，势必会有大量连接处于 SYN_RCVD 状态，从而占满整个半连接队列，无法处理正常的请求。

应对

• 增加 SYN 连接，也就是增加半连接队列的容量
• 减少 SYN + ACK 重试次数，避免大量的超时重发

私有保留地址

• A 类：10.0.0.0 - 10.255.255.255
• B 类：172.16.0.0 - 172.31.255.255
• C 类：192.168.0.0 - 192.168.255.255

OSI 七层模型

OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯，因此其最主要的功能是帮助不同类型的主机实现数据传输

• 物理层：最底层，OSI 第一层，利用传输媒介为数据链路层提供物理连接，实现比特流的透明传输
• 数据链路层：负责建立和管理节点间的链路，通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路
• 网络层：最复杂的一层，控制数据链路层和传输层之间的信息转发、建立、维持和终止网络的连接
• 传输层：OSI 下三层的蛀牙任务是数据通信，上三层主要任务是数据处理，而传输层是通信子网和资源子网的接口和桥梁，主要向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输，常见协议：TCP/IP 协议
• 会话层：用户应用程序和网络之间的接口，组织和协调两个会话进行之间的通信，并对数据交换进行管理
• 表现层：对来自应用层的命令和数据进行解释，对各种语法赋予相应的含义，并按照一定的格式传送给会话层，主要功能：数据格式处理、数据编码、数据压缩和解压缩、数据加密和解密
• 应用层：计算机用户，以及各种应用程序和网络之间的接口，功能是直接向用户提供服务，完成用户希望在网络上完成的各种工作

OSI 七层模型只是一种理想的模型，一般网络系统只涉及其中的几层，很少有系统能够具有所有的七层，并完全遵循它的规定，在七层模型中。每一层都提供特殊的网络功能，下面 4 层（物理层、数据链路层、网络层和传输层）主要提供数据传输和交换功能，即以节点到节点之间的通信为主，第四层作为上下两部分的桥梁，是整个网络体系结构中最关键的部分，上三层（会话层、表示层和应用层）则以提供用户与应用程序之间的信息和数据处理功能为主

cdn 原理

内容分发网络（Content Delivery Network）：将网站的内容通过中心平台分发到部署在各地的 CDN 节点进行缓存，再通过负载均衡技术将用户的请求转发到就近的服务器上获取所需内容，降低网络堵塞，提供访问网站的响应速度

当用户访问使用 CDN 服务的网站时，本地 DNS 服务器通过 CNAME 方式将最终域名请求重定向到 CDN 服务。CDN 通过一组预先定义好的策略(如内容类型、地理区域、网络负载状况等)，将当时能够最快响应用户的 CDN 节点 IP 地址提供给用户，使用户可以以最快的速度获得网站内容。

Content-type 常见头

• application/x-www-form-urlencoded
  原生 form 表单，如果不设置 enctype（在发送到服务器之前应该如何对表单数据进行编码），那么最终会以 application/x-www-form-urlencoded （空格转换为 "+" 加号，特殊符号转换为 ASCII HEX 值）方式提交
• mulitpart/form-data
  表单上传文件时，需要设置 enctype 为 mulitpart/form-data
• application/json
  消息主体为序列化的 JSON 字符串，可以提交复杂的数据结构，适合 RESTfule 接口，各大抓包工具都会以树行结构展示 json 数据，很友好
• text/html
  HTTP 作为传输协议，XML 作为编码方式的远程调用规范

HTTP

• 常见 HTTP 方法
  GET：请求访问被 URI 识别的资源
  POST：传输信息给服务器
  PUT：传输文件，保存到对于 URI 位置
  HEAD：获得报文首部，不返回报文主体，一般用于验证 URI 是否有效
  DELETE：删除文件，与 PUT 方法相反，删除对应 URI 位置的文件
  OPTIONS：查询相应 URI 支持的 HTTP 方法

• GET 和 POST 区别

  • get 重点是获取资源，post 重点是向服务器发送数据
  • get 请求数据通过 URL 请求，请求过程用户可见，post 传输数据通过 http 的 post 机制，将字段与对应值封存在请求实体中发送给服务器，此过程用户不可见
  • get 传输数据量小，受 URL 长度限制，效率高；post 传输大量数据，上传文件时只能通过 post 方式
  • get 是不安全的，URL 可见，可能会泄漏私密信息
  • get 只支持 ASCII 字符，向服务器传输的中文字符可能会乱码

• 常见响应码

  • 1xx：提示信息，代表请求已接受，继续处理
  • 2xx：成功
  • 3xx：重定向
    http 1.0 里面 302 具有二义性，在 http 1.1 中加入 303 和 307 就是为了消除二义性
    • 302
    • 303
    • 307
  • 4xx：客户端错误--请求有语法错误或请求无法实现
    401：Unauthorized 表示用户没有权限（用户名，密码错误等等）
    403：Forbidden 表示用户有权限，但未被授权访问特定资源
  • 5xx：服务端错误

HTTPS

• HTTP 缺陷
  通信使用明文未加密，内容可能被窃听，HTTPS 进行加密传输，防止窃听
  不验证通信方身份，可能遭到伪装，HTTPS 添加数字证书来验证双方身份，防止身份伪造
  无法验证报文完成性，可能被篡改，HTTPS 用数字签名，解决
  HTTPS 在浏览器上方有个锁

• HTTPS
  客户端浏览器在使用 HTTPS 方式与 Web 服务器通信阶段

  1. 证书验证
     浏览器发起 HTTPS 请求，要求与 Web 服务器建立 SSL 连接
     服务端返回 HTTPS 证书：Web 服务器收到客户端请求后，会生成一对公钥和私钥，并把公钥放在证书中发送给客户端浏览器
     客户端验证证书是否合法，如果不合法则提示告警
  2. 数据传输
     当证书验证合法后，在本地生成随机数
     通过公钥加密随机数，并把加密后的随机数传输到服务端
     服务端通过私钥对随机数进行解密
     服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

  为什么数据传输是对称加密？

  1. 非对称加密的加解密效率低，而 http 请求中通常是有大量的交互，非对称加密效率无法接受
  2. 在 HTTPS 的场景中只有服务端保存私钥，一对公私钥只能实现简单的加解密，所以采用对称加密

  本地随机数被窃取怎么办？

  证书验证时采用非对称加密实现，传输过程采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并存储在本地的，HTTPS 如何保证随机数不会被窃取？
  HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一范畴

  HTTPS 抓包
  HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。