目录
[1. 源端口号，目的端口号 和 udp 相同（前面文章介绍了udp）](#1. 源端口号，目的端口号 和 udp 相同（前面文章介绍了udp）)
[2. 4位首部长度 ------ TCP的报头长度](#2. 4位首部长度 —— TCP的报头长度)
[3. 选项 ------ option （可选的：可以有，可以没有）](#3. 选项 —— option （可选的：可以有，可以没有）)
[5. 16位校验和](#5. 16位校验和)
[TCP协议 的相关特性](#TCP协议 的相关特性)
[2.面向字节流 和 全双工](#2.面向字节流 和 全双工)
[2. 超时重传机制](#2. 超时重传机制)
前言：本章节是网络编程的理论基础。是一个服务器开发程序员的重要基本功。是整个网络课程中的重点和难点。也是各大公司笔试面试的核心考点。
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服务端代码
java
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客户端代码
java
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通过 确认应答 为核心，借助其他机制辅助，最终完成可靠传输。
错误答案：三次握手/四次挥手保证了可靠传输（错误❌！！！）