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发送数据时，需要先建立连接，什么时候关闭连接就决定是短连接还是长连接；
长连接和短连接的概念
- 短连接：每次接收到数据并返回响应后，都关闭连接，即是短连接。也就是说，短连接只能一次收发数据。
- 长连接：不关闭连接，一直保持连接状态，双方不停的收发数据，即是长连接。也就是说，长连接可以多次收发数据。
长连接和短连接区别
- 建立连接、关闭连接的耗时:短连接每次请求、响应都需要建立连接，关闭连接;而长连接只需要第一次建立连接，之后的请求、响应都可以直接传输。相对来说建立连接，关闭连接也是要耗时的，长连接效率更高。
- 主动发送请求不同:短连接一般是客户端主动向服务端发送请求;而长连接可以是客户端主动发送请求，也可以是服务端主动发。
- 两者的使用场景有不同:短连接适用于客户端请求频率不高的场景，如浏览网页等。长连接适用于客户端与服务端通信频繁的场景，如聊天室，实时游戏等。