TCP/IP五层模型,从上向下分别是:
网络上的大部分通讯协议都是基于TCP/IP模型实现的,例如一下这些常见的应用层协议:
DNS的执行流程如下:
总结来说:它包括了从本地DNS缓存查询开始,逐级向根域名服务器、顶级域名服务器、权威域名服务器的查询过程,最终返回所查询域名的IP地址给用户设备
根域名服务器在整个 DNS 体系中起着导航作用,帮助其他 DNS 服务器找到正确路径;顶级域名服务器针对某一类顶级域名进行管理;而权威域名服务器则具体负责某个域名区域内的详细信息解析工作,它们的关系如图所示:
执行流程如下:
GET请求和POST请求区别如下:
POST请求相比GET请求更加安全,但是POST请求地数据被封装在请求体中,用一些抓包工具就可以直接获取到其内容。只要是HTTP协议的,都不是安全的
301和302都是用于请求重定向地状态码,所谓的请求重定向是指访问某个URL的时候,会自动跳转另一个URL。但是它们,一个表示请求的资源已经被永久性(301)的移动到另一个位置,而302是临时的移动到另一个位置,客户端应该通过重定向到新的位置获取资源。它们主要的区别如下:
请求转发(Forword)和请求重定向(Redirect)区别如下:
请求转发:
@RequestMapping("/fw")
public void forward(HttpServletReguest reguest, HttpSeryletResponse response) throws ServletException,IOException{
request.getRequestDispatcher("/index.html").forward(request, response);
}
请求重定向:
@RequestMapping("/rt")
public void redirect(HttpServletRequest request, HttpServletResponse response) throws
IOException{
response.sendRedirect("/index.html");
}
HTTP在互联网通信中起着至关重要的作用,但是它存在一些安全性的问题,所以需要使用HTTPS来增强网络通信的安全。HTTP主要存在以下问题:
HTTPS具有以下的优点:
中间人攻击是指,正常情况下本应该是客户端和服务器进行交互的,但是在中间多出了一个中间人,盗取和篡改双方通讯的内容
所以说中间人攻击主要是有两个问题:
使用HTTPS就可以完美的解决中间人功能估计,HTTPS使用以下两种方式来解决:
CA认证证书:HTTPS 解决信任问题采用的是数字证书的解决方案,也就是服务器在创建之初,会先向一个大家都认可的第三方平台申请一个可靠的数字证书,然后在客户端访问(服务器端)时,服务器端会先给客户端一个数字证书,以证明自己是一个可靠的服务器端,而非中间人
加密通讯:使用加密通讯之后,第一次通讯的密钥只有在真正的服务器端报错,所以即使中间人拦截了信息,因为是密文并且没有密钥,所以是破解不了的
HTTPS是一种在HTTP协议的基础上通过SSL/TLS协议提供了加密处理和身份认证的网络协议,用于确保通信内容的安全性。HTTPS执行的流程如下:
加密套件是一组加密算法、密钥交换算法和摘要算法的集合,用于加密和认证网络通信的数据。它通常由以下几部分组成:
密钥交换算法:用于在通信双方之间安全地交换密钥的算法,例如RSA、Diffie-Hellman等
加密算法:用于对通信中的数据进行加密的算法,例如AES、3DES等
摘要算法:用于对通信中的数据进行摘要计算,以确保数据的完整性,例如SHA-256、SHA-1等
加密套件的选择对通信的安全性至关重要。通常,服务器和客户端在SSL/TLS握手过程中协商选择一种适当的加密套件来确保通信的安全性。这种协商过程可以确保通信双方都能够支持最强大的加密算法和最安全的密钥交换算法,以提供最高级别的安全性
TCP采用三次握手流程如下:
三次握手的目的有以下几点:
二次握手或四次握手并不是TCP协议所采用的标准握手流程,它们都存在一些问题:
二次握手:在这种情况下,客户端发送连接请求后,服务器直接发送确认,这样客户端并不能确认服务器的状态,容易造成连接的不稳定性和不可靠性。
四次握手:在这种情况下,多了一次确认的过程,增加了通信的开销,而且不必要,因为三次握手已经足够确保连接的可靠性。
因此,TCP采用三次握手的机制是为了在可靠地建立连接的同时,保证通信的高效性和可靠性
造成消息丢失和超时重传的场景有以下两种:
无论哪种情况,TCP不会一直重传丢失的消息,因为这样如果对方真正的下线,会造成系统资源浪费。所以TCP设计了两种重传策略:
TCP粘包和半包是数据传输中比较常见的问题。所谓的粘包问题就是指在数据传输的时候,在一条消息中读取到了另一条消息的部分数据,如下图:
半包是指接收端只收到了部分的数据,而非完整的数据的情况,如下图:
大部分情况下我们都把粘包问题和半包问题看成同一个问题,所以下文就用粘包问题来替代粘包和半包问题
粘包问题发生在TCP/IP协议中,因为TCP是面向连接的传输协议,它是以流的形式传输数据的,而流数据是没有明确开始和结尾的边界的,所以就会出现粘包问题
接下来我们用代码来演示一下粘包和半包问题,为了演示的直观性,我会设置两个角色:
服务端代码实现:
import java.io.*;
import java.net.*;
public class Server {
private static final int BYTE_LENGTH = 20;
public static void main(String[] args) throws IOException {
// 创建 Socket 服务器
ServerSocket serverSocket = new ServerSocket(8888);
// 获取客户端连接
Socket clientSocket = serverSocket.accept();
// 得到客户端发送的流对象
try (InputStream inputStream = clientSocket.getInputStream()) {
while (true) {
// 循环获取客户端发送的信息
byte[] bytes = new byte[BYTE_LENGTH];
// 读取客户端发送的信息
int count = inputStream.read(bytes, 0, BYTE_LENGTH);
if (count > 0) {
// 成功接收到有效消息并打印
System.out.println("接收到客户端的信息是:" + new String(bytes, 0, count));
}
}
}
}
}
客户端代码实现:
import java.io.*;
import java.net.*;
import java.nio.charset.StandardCharsets;
public class Client {
public static void main(String[] args) throws IOException {
String serverAddress = "127.0.0.1";
int port = 8888;
try (Socket socket = new Socket(serverAddress, port);
PrintWriter out = new PrintWriter(socket.getOutputStream(), true)) {
String message = "hello,world";
OutputStream outputStream= socket.getOutputStream();
for (int i = 0; i < 10; i++) {
outputStream.write(message.getBytes());
}
}
}
}
程序执行结果:
此时我们发现出现了粘包问题,正常应该是直接输出10次hello world 才对
粘包问题的常见解决方案有以下三种:
收、发固定大小的数据,服务端实现代码:
import java.io.*;
import java.net.*;
public class Server {
private static final int BYTE_LENGTH = 1024;
public static void main(String[] args) throws IOException {
// 创建 Socket 服务器
ServerSocket serverSocket = new ServerSocket(8888);
// 获取客户端连接
Socket clientSocket = serverSocket.accept();
// 得到客户端发送的流对象
try (InputStream inputStream = clientSocket.getInputStream()) {
while (true) {
// 循环获取客户端发送的信息
byte[] bytes = new byte[BYTE_LENGTH];
// 读取客户端发送的信息
int count = inputStream.read(bytes);
if (count > 0) {
// 成功接收到有效消息并打印
System.out.println("接收到客户端的信息是:" + new String(bytes, 0, count));
}
}
}
}
}
客户端实现代码:
import java.io.*;
import java.net.*;
import java.nio.charset.StandardCharsets;
public class Client {
private static final int BYTE_LENGTH = 1024;
public static void main(String[] args) throws IOException, InterruptedException {
String serverAddress = "127.0.0.1";
int port = 8888;
String message = "hello,world";
try (Socket socket = new Socket(serverAddress, port)) {
OutputStream outputStream= socket.getOutputStream();
byte[] bytes = new byte[BYTE_LENGTH];
int idx= 0;
for(byte b:message.getBytes()){
bytes[idx]= b;
idx++;
}
for (int i = 0; i < 10; i++) {
outputStream.write(bytes,0,BYTE_LENGTH);
}
}
}
}
运行结果:
后面是字符编码的问题
优缺点分析
从以上代码可以看出,虽然这种方式可以解决粘包问题,但这种固定数据大小的传输方式,当数据量比较小时会使用空字符来填充,所以会额外的增加网络传输的负担,因此不是理想的解决方案
这种解决方案的实现思路是将请求的数据封装成两部分:消息头(发送的数据大小)+消息体(发送的具体数据),如下图:
此解决方案的实现为以下三部分:
消息的封装类:
import java.nio.charset.StandardCharsets;
public class CustomProtocol {
private static final int HEAD_SIZE = 8; // 假设消息头固定为8个字节
public static byte[] toBytes(String context) {
// 协议体 byte 数组
byte[] bodyByte = context.getBytes(StandardCharsets.UTF_8);
int bodyByteLength = bodyByte.length;
// 最终封装对象
byte[] result = new byte[HEAD_SIZE + bodyByteLength];
// 借助 NumberFormat 将int 转换为 byte[]
NumberFormat numberFormat = NumberFormat.getNumberInstance();
numberFormat.setMinimumIntegerDigits(HEAD_SIZE);
numberFormat.setGroupingUsed(false);
// 协议头 byte 数组
byte[] headByte = numberFormat.format(bodyByteLength).getBytes();
// 封装协议头
System.arraycopy(headByte, 0, result, 0, HEAD_SIZE);
// 封装协议体
System.arraycopy(bodyByte, 0, result, HEAD_SIZE, bodyByteLength);
return result;
}
public int getHeader(InputStream inputStream) throws IOException {
int result = 0;
byte[] bytes = new byte[HEAD_SIZE];
inputStream.read(bytes, 0, HEAD_SIZE); // 得到消息体的字节长度
result = Integer.valueOf(new String(bytes));
return result;
}
}
客户端代码:
import java.io.IOException;
import java.io.OutputStream;
import java.net.Socket;
import java.util.Random;
public class MySocketClient {
public static void main(String[] args) throws IOException {
// 启动 Socket 并尝试连接服务器
Socket socket = new Socket("127.0.0.1", 9093);
// 发送消息合集(随机发送一条消息)
final String[] messages = {"hello world"};
// 创建协议封装对象
SocketPacket socketPacket = new SocketPacket();
try (OutputStream outputStream = socket.getOutputStream()) {
// 给服务器端发送 10 次消息
for (int i = 0; i < 10; i++) {
// 随机发送一条消息
String msg = messages[new Random().nextInt(messages.length)];
// 将内容封装为:协议头+协议体
byte[] bytes = socketPacket.toBytes(msg);
// 发送消息
outputStream.write(bytes, 0, bytes.length);
outputStream.flush();
}
}
}
}
服务器端代码:
import java.io.IOException;
import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class MySocketServer {
public static void main(String[] args) throws IOException {
// 创建 Socket 服务器端
ServerSocket serverSocket = new ServerSocket(9093);
// 使用线程池处理更多的客户端
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(100, 150, 100, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000));
while (true) {
// 获取客户端连接
Socket clientSocket = serverSocket.accept();
// 客户端消息处理
threadPool.submit(() -> {
processMessage(clientSocket);
});
}
}
// 客户端消息处理
private static void processMessage(Socket clientSocket) {
// Socket 封装对象
SocketPacket socketPacket = new SocketPacket();
// 获取客户端发送的消息对象
try (InputStream inputStream = clientSocket.getInputStream()) {
while (true) {
// 获取消息头(也就是消息体的长度)
int bodyLength = socketPacket.getHeader(inputStream);
// 消息体 byte 数组
byte[] bodyByte = new byte[bodyLength];
// 每次实际读取字节数
int readCount = 0;
// 消息体赋值下标
int bodyIndex = 0;
// 循环接收消息头中定义的长度
while (bodyIndex <= (bodyLength - 1) && (readCount = inputStream.read(bodyByte, bodyIndex, bodyLength)) != -1) {
bodyIndex += readCount;
}
bodyIndex = 0;
// 成功接收到客户端的消息并打印
System.out.println("接收到客户端的信息:" + new String(bodyByte));
}
} catch (IOException e) {
e.printStackTrace();
}
}
}
运行结果:
优缺点分析:
此解决方案虽然可以解决粘包问题,但消息的设计和代码的实现复杂度比较高,所以也不是理想的解决方案
以特殊字符结尾就可以知道流的边界了,它的具体实现是:使用Java 中自带的 BufferedReader 和Bufferedwriter ,也就是带缓冲区的输入字符流和输出字符流,通过写入的时候加上 \n 来结尾,读取的时候使用 readLine按行来读取数据,这样就知道流的边界了,从而解决了粘包的问题
服务器端代码:
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class ServerSocketV3 {
public static void main(String[] args) throws IOException {
// 创建 Socket 服务器端
ServerSocket serverSocket = new ServerSocket(9092);
// 使用线程池处理更多的客户端
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(100, 150, 100, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000));
while (true) {
// 获取客户端连接
Socket clientSocket = serverSocket.accept();
// 消息处理
threadPool.submit(() -> {
processMessage(clientSocket);
});
}
}
// 消息处理
private static void processMessage(Socket clientSocket) {
// 获取客户端发送的消息流对象
try (BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()))) {
while (true) {
// 按行读取客户端发送的消息
String msg = bufferedReader.readLine();
if (msg != null) {
// 成功接收到客户端的消息并打印
System.out.println("接收到客户端的信息:" + msg);
}
}
} catch (IOException ioException) {
ioException.printStackTrace();
}
}
}
客户端代码:
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.OutputStreamWriter;
import java.net.Socket;
public class ClientSocketV3 {
public static void main(String[] args) throws IOException {
// 启动 Socket 并尝试连接服务器
Socket socket = new Socket("127.0.0.1", 9092);
final String message = "hello world";
// 发送消息
try (BufferedWriter bufferedWriter = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()))) {
// 给服务器端发送 10 次消息
for (int i = 0; i < 10; i++) {
// 注意:结尾的\n 不能省略,它表示按行写入
bufferedWriter.write(message + "\n");
// 刷新缓冲区(此步骤不能省略)
bufferedWriter.flush();
}
}
}
}
运行结果:
优缺点分析:
以特殊符号作为粘包的解决方案的最大优点是实现简单,但存在一定的局限性,比如当一条消息中间如果出现了结束符就会造成半包的问题,所以如果是复杂的字符串要对内容进行编码和解码处理,这样才能保证结束符的正确性
四次挥手的具体流程如下:
TCP进行四次挥手的作用主要是有两点:
四次挥手时发送者最后一次等待时间是两个MSL(最大生存时间),目的就是确保最后一个ACK的可靠传输,在四次挥手的最后一步,接收方发送一个ACK给发送方,表示接受到了关闭连接的请求。发送方需要等待一段时间,确保这个ACK报文额能够可靠的传输到接受方。如果发送方在等待期间收到接收方的重传请求,可以重发ACK
TCP和UDP都是传输层的重要协议,但是它们存在以下几点不同: