TCP流套接字编程

TCP流套接字编程

ServerSocket API

        ServerSocket 是专门给服务器使用的 Socket 对象。

构造方法

普通方法

Socket API

        Socket 是客户端Socket，或服务端中接收到客户端建立连接（accept方法）的请求后，返回的服务端Socket。既会给客户端使用，也会给服务器使用。

构造方法

普通方法

         TCP 不需要额外使用一个类来表示“TCP 数据报”，因为 TCP 是以字节的方式流式传输的。 

TCP中的长短连接

TCP发送数据时，需要先建立连接，什么时候关闭连接就决定是短连接还是长连接：

        短连接：每次接收到数据并返回响应后，都关闭连接，即是短连接。也就是说，短连接只能一次收发数据。

        长连接：不关闭连接，一直保持连接状态，双方不停的收发数据，即是长连接。也就是说，长连接可以多次收发数据。

两者区别如下：

        建立连接、关闭连接的耗时：短连接每次请求、响应都需要建立连接，关闭连接；而长连接只需要第一次建立连接，之后的请求、响应都可以直接传输。相对来说建立连接，关闭连接也是要耗时的，长连接效率更高。

        主动发送请求不同：短连接一般是客户端主动向服务端发送请求；而长连接可以是客户端主动发送请求，也可以是服务端主动发。

        两者的使用场景有不同：短连接适用于客户端请求频率不高的场景，如浏览网页等。长连接适用于客户端与服务端通信频繁的场景，如聊天室，实时游戏等。

扩展了解：

        基于BIO（同步阻塞IO）的长连接会一直占用系统资源。对于并发要求很高的服务端系统来说，这样的消耗是不能承受的。

        由于每个连接都需要不停的阻塞等待接收数据，所以每个连接都会在一个线程中运行。一次阻塞等待对应着一次请求、响应，不停处理也就是长连接的特性：一直不关闭连接，不停的处理请求。实际应用时，服务端一般是基于NIO（即同步非阻塞IO）来实现长连接，性能可以极大的提升。

示例一：回显服务器

TCP服务端

import java.io.*;
import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Scanner;

public class TcpEchoServer {
    private ServerSocket serverSocket = null;

    public TcpEchoServer(int port) throws IOException {
        serverSocket = new ServerSocket(port);
    }

    public void start() throws IOException {
        System.out.println("启动服务器");
        while (true) {
            Socket clientSocket = serverSocket.accept(); // 使用这个 clientSocket 和具体的客户端进行交流.
            processConnection(clientSocket);
        }
    }

    // 使用这个方法来处理一个连接.
    // 这一个连接对应到一个客户端. 但是这里可能会涉及到多次交互.
    private void processConnection(Socket clientSocket) {
        System.out.printf("[%s:%d] 客户端上线!\n", clientSocket.getInetAddress().toString(), clientSocket.getPort());
        // 基于上述 socket 对象和客户端进行通信
        try (InputStream inputStream = clientSocket.getInputStream();
             OutputStream outputStream = clientSocket.getOutputStream()) {
            // 由于要处理多个请求和响应, 也是使用循环来进行.
            while (true) {
                // 1. 读取请求
                Scanner scanner = new Scanner(inputStream);
                if (!scanner.hasNext()) {
                    // 没有下个数据, 说明读完了. (客户端关闭了连接)
                    System.out.printf("[%s:%d] 客户端下线! \n", clientSocket.getInetAddress().toString(), clientSocket.getPort());
                    break;
                }

                // 注意!! 此处使用 next 是一直读取到换行符/空格/其他空白符结束, 但是最终返回结果里不包含上述 空白符 .
                String request = scanner.next();
                // 2. 根据请求构造响应
                String response = process(request);

                // 3. 返回响应结果.
                //    OutputStream 没有 write String 这样的功能. 可以把 String 里的字节数组拿出来, 进行写入;
                //    outputStream.write(response.getBytes());
                //    也可以用字符流来转换一下.
                PrintWriter printWriter = new PrintWriter(outputStream);
                // 此处使用 println 来写入. 让结果中带有一个 \n 换行. 方便对端来接收解析.
                printWriter.println(response);
                // flush 用来刷新缓冲区, 保证当前写入的数据, 雀食是发送出去了.
                printWriter.flush();

                System.out.printf("[%s:%d] req: %s; resp: %s \n", clientSocket.getInetAddress().toString(), clientSocket.getPort(),
                        request, response);
            }
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            // 更合适的做法, 是把 close 放到 finally 里面, 保证一定能够执行到!!
            try {
                clientSocket.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    public String process(String request) {
        return request;
    }

    public static void main(String[] args) throws IOException {
        TcpEchoServer server = new TcpEchoServer(6666);
        server.start();
    }
}

        因此在使用完毕之后，就要进行“释放”，UDP 的 socket 没释放是因为 socket 生命周期更长（跟随整个程序），数量也不多；TCP 这里的生命周期更短（这个请求完了就没了），也就是数量也会更多。 

TCP客户端

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintWriter;
import java.net.Socket;
import java.util.Scanner;

public class TcpEchoClient {
    private Socket socket = null;

    public TcpEchoClient(String serverIp, int serverPort) throws IOException {
        // Socket 构造方法, 能够识别 点分十进制格式的 IP 地址. 比 DatagramPacket 更方便.
        // new 这个对象的同时, 就会进行 TCP 连接操作.
        socket = new Socket(serverIp, serverPort);
    }

    public void start() {
        System.out.println("客户端启动!");
        Scanner scanner = new Scanner(System.in);
        try (InputStream inputStream = socket.getInputStream();
             OutputStream outputStream = socket.getOutputStream()) {
            while (true) {
                // 1. 先从键盘上读取用户输入的内容
                System.out.print("> ");
                String request = scanner.next();
                if (request.equals("exit")) {
                    System.out.println("goodbye");
                    break;
                }

                // 2. 把读到的内容构造成请求, 发送给服务器.
                PrintWriter printWriter = new PrintWriter(outputStream);
                printWriter.println(request);
                // 此处加上 flush 刷新保证数据确实发送出去了.
                printWriter.flush();

                // 3. 读取服务器的响应
                Scanner respScanner = new Scanner(inputStream);
                String response = respScanner.next();
                // 4. 把响应内容显示到界面上
                System.out.println(response);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) throws IOException {
        TcpEchoClient client = new TcpEchoClient("127.0.0.1", 6666);
        client.start();
    }
}

                             相当于打电话的两端，对象是不一样的

示例二：请求响应（短连接）

示例一只是客户端请求和服务端接收，并没有包含服务端的返回响应。以下是对应请求和响应的改造：

构造一个展示服务端本地某个目录（BASE_PATH）的下一级子文件列表的服务

（1）客户端先接收键盘输入，表示要展示的相对路径（相对BASE_PATH的路径）

（2）发送请求：使用客户端Socket的输出流发送TCP报文。即输入的相对路径。

（3）服务端接收并处理请求：使用服务端Socket的输入流来接收请求报文，根据请求的路径，列出下

一级子文件及子文件夹。

TCP服务端

TCP客户端

等待客户端建立TCP连接...

目前TCP客户端和服务端实现的功能和UDP差不多，但都存在几个问题：

对于服务端来说，处理一次请求并返回响应后，才能再次处理下一次请求和响应，效率是比较低

的。这个问题比较好解决：可以使用多线程，每次的请求与响应都在线程中处理。这样多个客户端

请求的话，可以在多个线程中并发并行的执行。

服务端解析请求，是只读取了一行，而客户端解析响应，是一直读取到流结束。可以想想为什么解

析请求时，没有读取到流结束？目前的业务，双方都已约定好业务是展示目录下的文件列表，且都只需要一种数据：请求传输的数

据代表要展示的目录；响应传输的数据代表文件列表：每一行为一个文件名。

如要提供更多的业务，如文件重命名，文件删除等操作时，就不能了。此时就需要提供更多的字段

来标识。一般我们需要设计更强大的协议。