目录
TCP的报文格式
1. 源端口号，目的端口号 和 udp 相同（前面文章介绍了udp）
2. 4位首部长度 —— TCP的报头长度
3. 选项 —— option （可选的：可以有，可以没有）
4.保留（6）位
5. 16位校验和
TCP协议 的相关特性
1.有连接
2.面向字节流 和 全双工
2.可靠传输
TCP可靠传输是如何达成的？
1.确认应答机制
2. 超时重传机制
3.连接管理
##建立连续(三次握手)##
——LISTEN(listen)
——ESTABLISHED(establshed)
##连接断开(四次挥手)##
※※TIME_WAIT※※:
TCP服务端代码
TCP客户端代码
常见面试题：TCP是如何保证可靠传输的？
前言：本章节是网络编程的理论基础。是一个服务器开发程序员的重要基本功。是整个网络课程中的重点和难点。也是各大公司笔试面试的核心考点。
TCP协议最大的特点，就是可靠传输！！！
TCP的报文格式
我们先来简单认识一下各个部分：
1. 源端口号，目的端口号 和 udp 相同（前面文章介绍了udp）
2. 4位首部长度 —— TCP的报头长度
（数据报 = 首部（报头 header）+ 载荷 （UDP））
TCP 的报头长度是不固定的（变长的） ，报头最短20字节（没有选项），报头最长是60字节（选项最多是 40 字节）
注意：这个长度范围 是 0 ~ 15,那是怎么表示 60 的呀？
这里有一个很巧妙的设定 —— 这个长度的单位是 “4字节”
换句话来说，选项都是4字节一个单位的（最小也是4字节的），
所以60字节就是有15个选项 ：15（x4字节）= 60（字节）
选项是什么？我们来介绍 一下这一部分：
3. 选项 —— option （可选的：可以有，可以没有）
选项也是报头的一部分，也就是说，有选项，报头就更长，没有选项，报头就更短
4.保留（6）位
前面介绍了udp 数据报最长 64kb 且固定，就很难受，TCP的设计大佬就搞了保留位，
保留位：就是虽然现在不用，但是先占个位置，留下了扩展的余地
5. 16位校验和
和udp 一样
剩下的，我们在后续 TCP协议 的相关特性那里介绍。
TCP协议 的相关特性
TCP协议 的特性 ： 有连接，可靠传输，面向字节流，全双工
我们结合代码来看（完整代码最下面有）
1.有连接
我们在服务器这边就要通过 accept 的方式来接受 内核的连接，建立连接的过程，在代码中并不能感受到，因为内核都帮我们处理好了，但是我们可以通过 accept 把内核里建立好的连接 拿上来，这就体现了 tcp 的有连接
包括在后续传入数据的时候，也不用指定对方的地址了，因为已经在 tcp 的连接里记录下来了。
2.面向字节流 和 全双工
这两个就是 字节流
一个 Socket 既可以读 又可以写 —— 全双工
2.可靠传输
在代码里体现不出来
可靠传输，是TCP中最核心的特性（初心）
这里的可靠传输，不是说，发送方把数据能够 100%的传输给接收方， 这样要求太高了
我们退而求次：
1）发送方发出去的数据之后，能够知道接收方是否收到数据
2）一旦发现对方没收到，就可以通过一系列的手段来 “补救”
TCP可靠传输是如何达成的？
这就要涉及到TCP中的以下机制了
1.确认应答机制
发送方 把数据 发给 接收方 之后，接收方 收到数据 就会给 发送方返回一个 应答报文（acknowledge ->简写成ack）
此时，发送方如果收到这个应答报文了，就知道自己的数据是否发送成功了
在网络传输数据时，可能会出现“后发先至”这样的情况，一个数据包在进行传输的过程中走的路径可能是非常复杂的，不同的数据包，可能走不同的路线
—— 那如何避免这种“后发先至”的情况呢？
TCP在此处要完成一下两个工作:
1.确保应答报文和发出去的数据，能对上号，不要出现歧义。
2.确保在出现“后发先至” 的现象时，能够让应用程序这边仍然按照 正确的顺序 来理解数据。
——那TCP是如何完成这两个工作的？
根据下面的 32位序号 和 32位确认序号来完成。
意思是，我们可以把发出去的数据编上序号，与此同时，我们的应答报文就可以针对刚才那条数据的序号进行应答。而发送方也可以根据应答报文的确认序号对应到之前发送的数据，应答报文还可以根据确认序号的大小 进行重新排序。
总结来说，这个序号就是一个整数，根据它的大小关系，来描述数据的先后顺序。
举个例子:
上面的图，其实还不够严谨，更准确的说，序号不是按照 “一条两条” 的方式来进行编号的，而是按照 字节 来编号的。(TCP是面向字节流的，没有一条两条的概念)
——那具体TCP是如何编号的呢？
我们看下图:
(ps:TCP传输数据的时候，初始序号一般不是从1开始，上图的序号只是假设)
我们再看一个图:传输数据的时候就可以这样表示
1.首先我们来看第一条数据:
这条数据表示 这一个TCP数据包里一共有1000个字节的载荷数据，其中第一个字节的 序号是1，就是在TCP报头的序号字段中，写“1”，
由于一共是1000个字节，此时最后一个字节的序号自然就是1000了，但是1000这样的数据并不在TCP报头中记录。
(TCP报头中只记录这一次传输的载荷数据的 第一个字节的序号，剩下其他字节的序号，都需要依次的推出)
2. 我们接下来来看确认应答那一条：
在 应答报文中，就会在 确认序号字段中 填写 1001 ，因为收到的数据是 1～1000，所以1001之前的数据，就都被主机B收到了，或者也可以理解成，B接下来要向主机A索要1001开始的数据，
之后依次类推 发送，应答...
通过特殊的 ack 数据包，里面携带的“确认序号”来告诉发送方，哪些数据已经被确认收到了，此时发送方，就知道了自己刚发的数据是到了还是没到， 这就是可靠传输
——那如何区分一个数据包是普通的数据，还是 ack 应答数据呢？
我们还是看报文格式那张图：
下图画红圈的那一位为 1 ，则表示 当前数据包是一个应答报文 ，此时该数据包中的 “确认序号字段” 就能生效
这一位 为 0 ，则表示当前数据包是一个普通报文，此时数据包中的"确认序号字段"是不生效的。
TCP的初心，就是为了实现可靠传输，而达成可靠传输的 最核心 的机制，就是 确认应答。
（ps:至于为什么确认序号用收到的最后一个字节的序号 + 1表示？我们讲到滑动窗口那里再介绍。）
2. 超时重传机制
上述的确认应答，描述的是一个比较理想的情况， 那如果网络传输的过程中，出现丢包了，这时候该怎么办？
那发送方，势必无法收到 ack（应答报文）啦，这就出bug了,
那此时就 使用 超时重传机制 来针对确认应答，进行补充。
——首先，我们要了解，为什么会丢包？
我们可以把 网络想象成 错综复杂的公路网，在公路上就会有很多很多的收费站，
平时，车少，收费站的车都会快速通过，很少会出现堵车情况 ；
但是在一些 节假日的时候，收费站就经常会堵车，
然后在网络中，“收费站” 可以理解成一些 “路由器/交换机”，如果数据包太多了，就会在这些路由器/交换机 上出现 “堵车”，但是 路由器 针对 “堵车” 的处理，往往是比较粗暴的，它不会保存积压的数据包，而是会把其中的大部分数据包直接丢掉。（这些被丢掉的数据包就从网络上消失了，这就是丢包）
—— 由于丢包是一个“随机” 的事件，因此在上述 tcp 传输的过程中，丢包就存在两种情况：
1.传输的数据丢了
2.返回的 ack 丢了
但是站在发送方的角度，其实无法区分这两种情况。所以，无论出现上诉那种情况，发送方都会进行 “重新传输”。
重传操作，大幅度提升了数据能够被传过去的概率，是一个很好的丢包补救措施。
–– 那发送方是何时进行重传呢？
这里有一个 等待时间
我们的发送方，在发出去数据之后，会等待一段时间，如果这个时间之内，ack来了，此时就自然视为 数据到达;
如果达到这个时间之后，数据还没有到，就会触发 重传机制。
超时重传––超过了等待时间 再重传。
––那这个等待时间是多少呢？
不确定。
1.初始的等待时间，是可以配置的，不同的系统上都不一定一样，也可以通过修改内核参数来引起这个时间变化。
2.等待的时间，也会动态变化，每多经历一次超时，等待时间都会变长，但也不是一直变长，重传若干次时，时间拉长到一定程度，会认为数据再怎么重传也没用了，就会放弃 tcp连接(会触发TCP的重置连接操作)
––但是这里就有个问题了，我们看一下第二种丢包情况:
站在主机B 的视角，就收到了两条一样的数据，很明显，这就出bug了，就比如你买东西给商家转账，然后ack丢了，触发重传，又发了一次钱。
但是这个不用担心，TCP已经帮我们解决了，TCP会有一个“接收缓冲区”，就是一个内存空间，会保存当前已经收到的数据请，以及数据的序号。接收方如果发现，当前发送方发来的数据，已经在接收缓冲区中存在了，接收方就会直接把这个后来的数据丢掉。确保应用程序进行 read 的时候，读到的只有一条数据。
而且，到了缓冲区，不仅可以去重 ，还能进行重新排序，确保发送的顺序，和应用程序读取的顺序是一致的。
3.连接管理
建立连接+断开连接
这就来到了，面试中，最经典的问题了:
三次握手(建立连接) 和 四次挥手(断开连接)
##建立连续(三次握手)##
TCP这里的握手，是给对方传输一个简短的，没有业务数据的数据包，通过这个数据包，来唤起对方的注意，从而触发后续的操作
TCP的三次握手––TCP在建立连接的过程中，需要通信双方一共“打三次招呼”才能完成连接的建立
––那具体是怎么打招呼的，我们画图来解释:
A想和B建立连接，A就会主动发起握手操作，在实际开发中，主动发起的一方，就是所谓的“客户端”，被动接受的一方就是“服务器”。
syn:同步报文段，也是一个特殊的TCP数据包，没有载荷(就是不携带业务数据)(业务数据就是应用层数据包)
上图画圈那一位(syn),如果是1，就表示这个报文是一个同步报文段，如果这一位是0，就不是同步报文段。
上诉了解完，我们就可以画握手的图了∶
此时，握手完成，A和B记录了对方的信息，也就是 构成了“逻辑”上的连接。
但是，这怎么是四次呢？不是三次握手吗?
这是因为，在建立连续的过程，通信双方都要给对方发起syn,也都要给对方反馈ack，虽然一共是4次握手，但是中间两次，恰好可以合并成一次。(ACK和第二个syn都是内核触发的，是同一时间的，所以可以合并)
––那为什么要握手呢？
这于“可靠传输”密切相关。
在进行确认应答 和 超时重传有个大前提
–>当前的网络环境是基本可用的，通畅的
而“三次握手”的核心作用:
1.投石问路，确认当前网络是否是通畅的
2.要让发送方和接收方 都能确认自己的发送能力和接收能力正常的
上诉，是“可靠传输”的前提条件。
3.让通信双方，在握手过程中，针对一些重要的参数，进行协商。
握手这里要协商的信息， 其实是有好几个的， 但是此处不做过多讨论.
但是至少要知道， tcp 通信过程中的序号从几开始， 是双方协商出来的(一般不是从 1 开始的)
每次连接建立的时候，都会协商出一个比较大的， 和上次不太一样的值.
这种设定方式是避免前朝的剑，本朝的官，有的时候网络如果不太好，客户端和服务器之间可能会断开连接，再重新建立连接，重连的时候就可能在新的连接好了之后，就连接的数据姗姗来迟，而这种迟到的数据，应该要丢掉，不应该让这个数据影响到现在的数据，
——那如何区分这个是否是上一个数据?
就是通过上述序号的设定规则来实现，如果发现收到的数据序号和当前正常数据的序号差异非常大，就可以判定为是上一个数据，就可以直接丢掉了。
好，接下来我们介绍一下这张图:
——LISTEN(listen)
服务器端的状态.
服务器这边socket 创建好 并且把端口号绑定好，此时就会进入listen状态。
此时就允许客户端随时来建立连续了。
——ESTABLISHED(establshed)
客户端，服务器都会有的状态。
连接建立完成，接下来可以进行正常通信了。
##连接断开(四次挥手)##
建立连接，一般都是客户端主动发起的，断开连接，客户端和服务器都可以主动发起。
我们画图来看:
这个FIN是什么？
FIN: 结束报文段
这一位如果为 1， 那他就是一个结束报文段，然后就和对方断开连接。
然后∶
此时连接就断开了，这个时候，就相当于A和B都把对端的信息删除了。
然后我们想一想，和三次握手相比，此处的四次挥手，能否把中间的两次交互 合二为一?
–––不一定。
––不能合并的原因 ––> ACK 和 第二个FIN的触发时机是不同的。
ACK是内核响应的，B收到FIN,就会立即返回ACK, 而第二个 FIN 是应用程序的代码触发，B这边调用了 close方法，才会触发FIN。
从服务器收到FIN(同时返回ACK)，再到执行到close，发起FIN，这中间要经历多久，是不确定的。
FIN会在socket对象close的时候，被发起，可能是手动调用 close,也可能是进程结束。
ps: 如果我这边代码 close没写或没执行到，是不是第二个FIN就一直发不出去?
–––有可能。
正常的四次挥手，就是正常的流程断开的连接，
不正常的挥手(没挥完四次)，异常的流程断开连接。
––那什么时候可以合并呢?
TCP中还有一个机制–>延时应答(之后会介绍)，能够拖延ACK的回应时间，一旦ACK滞后了，就有机会和下一个 FIN 合并在一起了。(概率性问题)
这个大图也画出了四次挥手的过程，我们来看看:
——CLOSED:
连接已经彻底断开，可以释放了
※※TIME_WAIT※※:
哪一方，主动断开连接，哪一方就会进入TIME_WAIT(等待)，
TIME_WAIT状态就是为了处理最后一个ACK丢失 这种情况:
如果最后一个ACK丢了，站在B的角度，没收到应答报文，B就会触发超时重传，重新把刚才的FIN传一遍，但是已经不会有人再响应了，B也就永远也收不到ACK了。
所以A这边使用TIME_WAIT状态进行等待，等待的这个时间，如果最后一个ACK丢失，然后B重传FIN, A就能接受到，然后返回ACK。
(TIME_WAIT等待时间是2MSL(MSL:可配置的参数))
ps∶ 网络传输数据的基本单位:
段–>segment 包–>packet
报–>datagram 帧–>frame
但是，当引入 “可靠性” 的时候，会 降低传输效率(多出了等待ack的时间，单位时间内的传输的数据就少了)，提高复杂程度，（这也是UDP不被TCP完全取代的原因，当特别需要性能的场景，UDP肯定还是更胜一筹的。）
TCP服务端代码 import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import java.io.PrintWriter; import java.net.ServerSocket; import java.net.Socket; import java.util.Scanner; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; /** * @Author: iiiiiihuang */ //字节流通信方式 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("服务器启动！"); ExecutorService service = Executors.newCachedThreadPool(); while(true) { //通过 accept,把内核中已经建立好的连接拿到应用程序中 //建立连接的细节流程是内核自动完成的，应用程序 “捡现成的” 就好 Socket clientSocket = serverSocket.accept(); //创建线程来调用processConnection，这样就可以并发执行了（好几个客户端同时处理）（多线程） // Thread t = new Thread(() -> { // processConnection(clientSocket); // }); // t.start(); service.submit(new Runnable() { @Override public void run() { processConnection(clientSocket); } }); } } //通过这个方法来处理 当前的连接 public void processConnection(Socket clientSocket) { //先打印日志，表示当前有客户端连上了 System.out.printf("[%s:%d] 客户端上线！\n", clientSocket.getInetAddress(), clientSocket.getPort()); //接下来进行数据的交互 try (InputStream inputStream = clientSocket.getInputStream(); OutputStream outputStream = clientSocket.getOutputStream()) { //使用try()方法，可以避免后续用完了流对象，忘记关闭 //由于客户端发来的数据，可能是多条数据，所以针对对条数据，就得循环处理 while(true) { Scanner scanner = new Scanner(inputStream); if(!scanner.hasNext()) { //此时连接就断开了，循环就要结束 System.out.printf("[%s:%d] 客户端下线！\n", clientSocket.getInetAddress(), clientSocket.getPort()); break; } /** * 1.读取请求并解析，此处就以 next 来作为读取请求的方式 */ //next 的规则是读到“空白符” 就返回 //后续客户端发起的请求，会以空白符作为结束的标记（此处约定为\n） String request = scanner.next(); /** * 2.根据请求，计算响应 */ String response = process(request); /** * 3.把响应写回到客户端 */ //（1）可以把String 转为字节数组，写入到 OutputStream //（2）也可以使用 PrintWriter 把 OutputStream 包裹一下，来写入字符串 PrintWriter printWriter = new PrintWriter(outputStream); //此处的打印就不是打印到控制台了，而是写入到 outputStream 对应的流对象中，也就是写入到 clientSocket 里面 //这个数据自然就通过网络发送出去了（发给当前这个连接的另外一端） //此处使用 println （带有\n）也是为了后续 客户端那边 可以使用 scanner.next 来读取数据。 printWriter.println(response); //此处还有一个操作 ———— 刷新缓冲区 （如果没这个操作，可能数据依然是在内存中的，没有被写入网卡） printWriter.flush(); /** * 4.打印这次请求交互过程的内容 */ System.out.printf("[%s:%d] req = %s , resp = %s\n", clientSocket.getInetAddress(), clientSocket.getPort(), request, response); } }catch (IOException e) { e.printStackTrace(); } finally { try { //在这里进行clientSocket 的关闭，防止文件资源泄露 //这是因为本方法（processConnection）就是在处理一个连接，这个方法执行完毕，这个连接也就处理完了 clientSocket.close(); } catch (IOException e) { throw new RuntimeException(e); } } } public String process(String request) { //回显服务器，响应和请求一样 return request; } public static void main(String[] args) throws IOException { TcpEchoServer server = new TcpEchoServer(9090); server.start(); } }
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; /** * @Author: iiiiiihuang */ public class TcpEchoClient { private Socket socket = null; public TcpEchoClient(String serverIp, int serverPort) throws IOException { //在创建Socket的同时，要和服务器 “建立连接”， 此时就得告诉 Socket 服务器在哪里 （如何连接，不需要我们手动干预，内核自动完成了） socket = new Socket(serverIp, serverPort); } public void start() { Scanner scanner = new Scanner(System.in); try (InputStream inputStream = socket.getInputStream(); OutputStream outputStream = socket.getOutputStream()){ PrintWriter printWriter = new PrintWriter(outputStream); Scanner scannerNetwork = new Scanner(inputStream); while (true) { /** * 1.从控制台读取用户输入的内容 */ System.out.print("->"); String request = scanner.next(); /** * 2.把字符串作为请求，发送给服务器 */ printWriter.println(request); printWriter.flush(); /** * 3.从服务器读取响应 */ String response = scannerNetwork.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", 9090); client.start(); } }
常见面试题：TCP是如何保证可靠传输的？
正确答案：TCP通过 确认应答 为核心，借助其他机制辅助，最终完成可靠传输。
错误答案：三次握手/四次挥手保证了可靠传输（错误❌！！！）