当前位置：首页 > news >正文

【JavaEE初阶 — 网络编程】TCP流套接字编程

news 文章来源：https://blog.csdn.net/2402_84916296/article/details/143997154 2025/1/11 2:24:43

TCP流套接字编程

1. TCP ＆ UDP 的区别

TCP 的核心特点是面向字节流，读写数据的基本单位是字节 byte

2 API介绍

2.1 ServerSocket

定义

ServerSocket 是创建 TCP 服务端 Socket 的API。

构造方法

方法签名	方法说明
ServerSocket(int port)	创建一个服务端流套接字Socket，并绑定到指定端口

所以服务器启动，需要绑定端口号

方法

方法签名	方法说明
Socket accept()	开始监听指定端口(创建时绑定的端口)，有客户端连接后，返回一个服务端Socket对象，并基于该Socket建立与客户端的连接，否则阻塞等待
void close()	关闭此套接字

2.2 Socket

Socket 是客户端 Socket ，或服务端中接收到客户端建立连接(accept方法)的请求后，返回的服务端Socket。

不管是客户端还是服务端Socket，都是双方建立连接以后，保存的对端信息，及用来与对方收发数据的。

构造方法

方法签名	方法说明
Socket(String host, int port)	创建一个客户端流套接字Socket，并与对应IP的主机上，对应端口的进程建立连接

这个方法的两个参数，都是服务器的IP ＆端口，这个版本的构造方法，就是给客户端用的，服务器怎么通过这个类来构造对象呢？后续再来看；

方法

方法签名	方法说明
InetAddress getlnetAddress()	返回套接字所连接的地址
InputStream getlnputStream()	返回此套接字的输入流
OutputStream getOutputStream()	返回此套接字的输出流

TCP没有 send()，receive() 这样的操作，但是 TCP 调用 getlnputStream() 会得到个 InputStream 对象；调用 getOutputStream()，得到一个 OutputStream 对象，这两个对象是字节流对象；

虽然 Socket 自身没有读写操作，但是 Socket 可以拿到字节流对象，就可以通过字节流对象，来进行读写操作；

3. 通过TCP实现回显服务器

TCP Echo Server

创建关联对象

通过构造方法，绑定关联的端口号（和 UDP类似，都是在构造对象的时候，绑定端口号）

实现 start()

处理客户端发送的连接

TCP 和 UDP 服务器 start() 的主循环的第一步有所区别：

UDP 进入主循环，就可以直接处理请求，根据请求计算响应，把响应返回客户端；
TCP服务器，进入主循环后，因为 TCP 是有连接的，所以第一步是先处理客户端发来的连接；
这个连接就类似于打电话，在客户端打电话给服务器时，服务器要先接通电话，才可以进行后续的正常通信；

所以TCP服务器进入主循环的第一步，就是进行接通电话的操作，而拨号操作，是客户端来完成的；

调用 ServerSocket 对象底下的 accept() 方法，起到接听电话的作用；

还需要接收 accept() 方法的返回值：

如果客户端和服务器确实已经建立连接了，那 accept() 是可以拿到这个请求连接的；
如果客户端没有发起连接，那么 accept() 就会产生阻塞，和前面的 receive() 类似；

TCP 服务器后续通过对clientSocket 进行读写数据，来和客户端进行通信；

进一步理解 ServerSocket 和 Socket 的职责划分

处理一个客户端的连接

处理连接的过程比较复杂，因此我们把这个操作封装成一个方法；

可能会涉及到多个客户端的请求和响应，如果服务器接收到多个请求，就要返还给客户端多个响应；

服务器与客户端成功连接，打印日志：

这两个方法可以拿到对端（客户端）的 IP ＆端口号；

获取输入流对象＆输出流对象

打印出客户端的IP＆端口号后，就需要进一步地处理客户端的请求和响应，需要借助 Socket 类内置的 InputStream ＆ OutputStream 来处理这些请求和响应

这里获取到的是输入流对象，后续提供这个对象，来读取客户端的请求；

接下来获取输出流对象，并且处理异常：

拿到输入流对象＆输出流对象后，后续读取请求，就使用输入流对象；返回响应，就把响应的内容写入输出流对象中；

接下来，在 try 的代码块中，实现读取请求和返回响应的操作，这些操作分成三步

读取请求并解析
根据请求计算响应
返回响应给客户端

因为在一次连接中，这三个操作可能会解析多次，所以我们提供 while 循环来处理

读取请求

下列操作，读取到的请求是一个字节数组，还需要手动把字节数组再转成字符串，才方便后续的处理和打印：

我们可以借助 Scanner 来进行更简单直接的读取操作，既可以读请求，读出来的请求又已经是一个字符串；

把刚刚从 Socket 中拿到的 InputStream 填入 Scanner 中，后续通过 Scanner 直接读取请求中的内容；
如果 Scanner 没有再读取到数据，说明连接断开，就可以结束循环了

所以读取请求，可以直接借助 read()，也可以借助 Scanner 来辅助完成

补充

Scanner 可以控制处理台输入，又可以控制处理文件的输入，还可以控制处理网络的输入；
Scanner 的构造方法：

Scanner 的构造方法，填入的是一个InputStream 对象

根据请求计算响应

当前编写的是一个回显服务器代码，所以可以直接在计算响应的逻辑返回请求即可

返回响应给客户端

下列写法，会直接拿到 response 中的字节数组，然后通过 outputStream 提供的 write()，来写入输出流对象即可；

这种计算响应的方法，是提供字节的方式填充输出流对象；

除了上述写法，我们还可以利用字符流的方式：

这里的 writer 和 System.out 起到的的效果类似，所以 println，printf 等等都可以通过调用

打印返回响应的日志和连接断开的日志

服务器一次连接可处理多个请求的原理

服务器 start() 的代码块中， process() 方法处理请求返回响应的逻辑，相当于嵌套了两层 while 循环：

因此，可以在服务器与客户端的一次连接中，服务器处理多个请求；

如果在一次连接中，客户端发送多次请求，服务器就返还多个响应（打一次电话可以说一句话或者很多句话）；

补充

一个连接一个请求（短连接），一个连接多个请求（长连接）；
因为连接过程的开销非常大，所以在日常开发中，更主流的是长连接，一个连接处理多个请求；
就好比锁消除，针对要加锁的多个逻辑，每个逻辑都进行加锁，开销非常大，所以更科学的做法是把这些逻辑合在一起，只进行一次加锁；（和领导汇报工作成果，应该在一次电话中一次性汇总完毕，而不是打多次电话。每次电话只汇报一个成果）

TCP Echo Client

创建 Socket 对象

Socket 在客户端和服务器都可以使用，服务器的 Socket 通过调用accept()拿到，但是客户端的 Socket 就需要通过实例来创建对象；

实现客户端构造方法

在客户端的构造方法中，传入服务器的IP和端口号；

传到构造方法中的字符串IP地址（类似127.0.0.1这样的字符串），不需要任何转换；

对比UDP 的客户端，TCP客户端在构造方法在实例Socket对象后，就会在底层和对端建立TCP连接，连接好后，服务器会记录对端的信息（实例化Socket对象时传入的IP和端口号）；

因此，服务器的IP和端口号，在TCP客户端中就不需要再创建变量来保存了；

从控制台中读取请求，发送给服务器

从控制台中读取用户输入信息作为请求

为了实现客户端能够和服务器在一次连接的情况下，发送多次请求，我们设置一个循环：

这步操作可以读取刚刚输入控制台的一行信息，读取到的信息作为客户端的请求；

拿到输入流＆输出流

之后就把这个请求写入 Socket 对象中，写的时候也需要拿到Socket对象的 InputStream 输入流＆ OutputStream 输出流；

为了使用方便，可以对拿到的输入流和输出流再套一层壳

完善循环逻辑

所以在主循环中，第一步操作是从控制台中读取用户输入，把读取到的输入设置为请求：

第二步就是把请求发送给服务器

第三步，就是读取服务器返回的响应，并且把读取到的响应打印到控制台

客户端与服务器交互过程

区分客户端与服务器的 Socket 对象

下列服务器和客户端的两个 socket 对象，分别在不同进程中，甚至在不同主机中，因此绝对不是同一个对象；

这两个对象存在密切的关联关系，可以把这两个 socket 对象理解为两部电话：

接通这两部电话后，从A听筒说话，B可以听见；从B听筒说话，A可以听见（从一边对Socket对象写数据，另一边的 Socket 对象就可以读到）；
但是这两个对象绝对不是同一部电话；

处理细节问题

问题一：冲刷缓冲区

完善 main 方法

程序运行结果

关掉客户端：

再启动一次客户端，并且发送一个数据，并且一敲回车，发现没有反应：

为什么没有反应呢？因为其实刚刚客户端代码，并没有真的把请求发送出去：

这个操作只是把数据放到 “发送缓冲区” 中，还没有真正写入网卡里；

发送缓冲区其实就是一块内存空间，对网络/硬盘写数据是一个非常低效的操作，如果频繁地调用这些比较低效的操作，程序运行是非常缓慢的；
为了提高效率，就引入一个内存缓冲区，把要写入的数据都放入缓冲区中，再统一进行发送，这样可以减小写硬盘和写网络的次数；
但是提高效率的同时，也会产生副作用，就是调用 writer.println 这样的操作，并没有真正地触发发送数据操作，而只是把数据写入缓冲区；
当然，把数据写入缓冲区，而不是直接发送这样的行为，是 PrintWriter的行为，如果不套壳，是可以直接发送的；
但是在实际开发中，广泛使用了缓冲区这样的概念，调用flush()来刷新缓冲区这个操作是非常关键的；

如何真正地把数据发送出去呢？我们要使用刷新操作（调用 flush() 方法来冲刷缓冲区），把缓冲区的数据强制写入 IO 设备中：

客户端服务器交互结果

问题二：针对 hasNext 对一个完整请求/响应设置标识符

println 的操作，会自动加上一个 \n ：

但是如果在这个代码中不加这个 \n，直接使用 print行不行呢？

我们重新启动一下客户端，并且发送内容，发现客户端又没有反应了，并且服务器也没有读到信息：

造成上述原因，是因为 next() 的问题，修改成 print 后，客户端输入的数据也是发送到服务器上了，并且服务器也收到了，但是服务器并没有真正处理，因为服务器有一个hasNext()判断：

补充

hasNext() 的行为是，判断当前收到的数据是否包含“空白符”，什么是空白符呢？
换行，回车，空格，制表符，翻页符......都是空白符；
遇到空白符，hasNext()才会认为是一个完整的 next，否则在遇到空白符之前，hasNext() 都会阻塞。

所以刚刚在修改成 print 之后，发送的内容是不包含空白符的内容，hasNext() 就会阻塞而无法进入下面读取请求的逻辑；

总结

使用 println，是在约定一个请求/响应，是在使用 \n 作为结束标记，对端在读取数据的时候，也会在读取到 \n 时，判断读取到一个完整的请求/响应；
这是我们在使用TCP时，特别需要注意的事项，并且和UDP不一样；
UDP是以 DatagramPacket 作为单位的，但是TCP则是以字节为单位，但是实际上一个请求，往往是以多个字节构成的；
到底多少个字节为一个完整的请求/响应，就需要程序员想办法标记出来，引入分割符是标记一次完整请求/响应的典型方式，不一定是换行，也可以是其他分割符；

问题三：根据不同Socket的生命周期判断是否需要手动关闭

在TCP服务器刚刚编写的代码中，涉及两种Socket：

ServerSocket的生命周期，贯彻整个服务区进程，不需要手动关闭

clientSocket 的生命周期是一次连接，而不是整个服务器进程；

所以每个客户端连接，都会创建一个新的 clientSocket，每个客户端断开，这个对象就应该 close() 了，但是当前代码并没有对 clientSocket 进行 close() 释放；
没有在每次连接结束后，对 clientSocket 进行关闭，就会造成文件资源泄漏的问题（文件一直在打开，而不进行关闭，在打开到一定程度，会把文件描述表耗尽，就无法继续打开新文件）

在 poccessConnection() 方法的逻辑执行完毕之后，我们就可以对 clientSocket 进行关闭

总结

对于是否需要手动关闭 Socket ，需要我们分析请求它的生命周期是跟随整个进程，还是跟随某个环节；
如果是跟随整个进程，那么可以不手动关闭 Socket；如果是每个请求都会创建应该 Socket，或者每一次连接都会创建一个 Socket，或者某一个环节的执行周期，会创建一个Socket，这样的情况，就需要我们手动关闭 Socket；

问题四：服务器无法同时等待 accept() ＆等待已连接的客户端发送响应

一个服务器能同时给多个客户端提供服务，那么刚刚编写的TCP服务器也可以处理多个请求吗？我们关掉客户端，再重新启动多个客户端：

补充：修改同时启动多个客户端的IDEA设置

IDEA 会默认只启动一个客户端，再启动别的客户端，会先关闭上一个启动的客户端；我们通过这里的设置，就可以让 IDEA 启动多个客户端；

设置好后，我们再来重新启动两个客户端，并且先后发送请求：

结果在第二个客户端发送请求时，又卡住了，并且第一个创建的客户端多次发送请求的操作是没问题的，服务器都会有一个正常响应，但是第二个客户端无论怎么发送请求，都不会有响应：

并且我们通过服务器日志，可以发现，在第二个客户端上线时，并没有再次打印日志；

如果我们关掉第一个客户端，第二个客户端发送的请求，会马上被服务器接收，并且返回响应

所以当前代码，TCP服务器在同一时刻，只能处理一个客户端发送的请求；

针对上面出现的问题，我们对服务器的处理请求，返回响应这一块代码的关键逻辑进行分析：

如果同一时刻，有多个客户端对一个服务器进行连接，那么第一个和服务器连接的客户端1：

所以当前这个服务器代码，如果已经在处理一个客户端的请求，就没办法处理另一个客户端的请求，服务器代码会卡在循环中，无法重新调用 accept()连接新的服务器，直到连接的客户端退出，导致循环终止；

总结

当前服务器代码，无法同时等待 accept 和等待用户请求；在等待客户端发送请求的时候，没办法等待 accept() ，这个时候，如果有新的客户端连接，也无法接听电话（一个专业销售没办法在给先来的顾客讲解产品的时候，又去接待低级销售后面揽入店的顾客）；
因此，服务器的代码，导致服务器一次只能处理一个客户端发送的请求，这个代码是不合理的；

4. 服务器引入多线程

如果只是单个线程，无法同时响应多个客户端；为了解决这个问题，此处给每个客户端都分配一个线程；

在服务器主线程中，就只是进行 accept()，每次有新的客户端 accept() 连接成功，就创建一个新的线程，又新线程负责完成，后续对客户端 Socket 对象的引用 clientSocket 的读写操作；

引入线程之后，重新启动服务器和两个客户端，可以发现服务器打印了两个带着不同端口号的日志；

因此，在引入线程之后，服务器可以一边等待请求，一边等待 accept() 连接新的客户端；

5. 服务器引入线程池

客户端连接，服务器就会创建新线程，客户端断开连接，客户端就会销毁线程，为了避免频繁创建销毁线程，也可以引入线程池；

线程池

对于在服务器引入线程池，一般不会使用 newFixedThreadPool，因为会创建一个固定线程数的线程池，意味着同时处理的客户端连接数目就固定了；

把任务都交到线程池中，线程池已经预先创建好了一些线程，提前创建好的线程就可以立刻投入工作，从而减少再去创建线程的开销；

线程不是越多越好，如果线程数量过多，CPU的利用率无法再被提高，还会导致系统调度速度下降；并且创建线程也是需要系统资源的，系统总体资源是有限的（一个主机差不多只能创建几千个线程）；

无论是多线程，还是线程池，一个线程都对应一个客户端，并且一个主机创建的线程数目是有上限的，那如果有成千上万个客户端，同时访问一个服务器（一台主机），该怎么办呢？

IO多路复用/IO多路连接（这里不重点讲解，因为JVM中没有原生的 IO 多路复用 API，而是把API重新封装，已经不仅仅是多路复用了，后续会详细讲解针对 Java 的 IO多路复用所使用的 NIO,Netty 等知名网络框架，当前讲的IO是 BIO/Blocking IO）；

扩展

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

由于每个连接都需要不停的阻塞等待接收数据，所以每个连接都会在一个线程中运行。
一次阻塞等待对应着一次请求、响应，不停处理也就是长连接的特性:一直不关闭连接，不停的处理请求。

实际应用时，服务端一般是基于NIO(即同步非阻塞IO)来实现长连接，性能可以极大的提升。

6. 长短连接

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

长连接和短连接的概念

短连接：每次接收到数据并返回响应后，都关闭连接，即是短连接。也就是说，短连接只能一次收发数据。
长连接：不关闭连接，一直保持连接状态，双方不停的收发数据，即是长连接。也就是说，长连接可以多次收发数据。

长连接和短连接区别

建立连接、关闭连接的耗时:短连接每次请求、响应都需要建立连接，关闭连接;而长连接只需要第一次建立连接，之后的请求、响应都可以直接传输。相对来说建立连接，关闭连接也是要耗时的，长连接效率更高。
主动发送请求不同:短连接一般是客户端主动向服务端发送请求;而长连接可以是客户端主动发送请求，也可以是服务端主动发。
两者的使用场景有不同:短连接适用于客户端请求频率不高的场景，如浏览网页等。长连接适用于客户端与服务端通信频繁的场景，如聊天室，实时游戏等。