引言

我们知道客户端（Client）A 和服务器端（Server）B 的通信方式可分为：全双工、半双工、单工：

• 单工：A 可以发给 B ，B 不能发给 A ，叫做单工
• 半双工：A 可以发给 B , B 也可以发给 A ，但是两者的步骤不能同时进行，即 A 给 B 发信息的时候，B 不能给 A 发。
• 全双工：即客户端 A 在给服务器端 B 发信息的同时，服务器端 B 也可以给客户端 A 发送信息。

TCP 属于全双工。 欢迎大家加入java交流社区 点此进入  备注“csdn”还可获取文末文档哦

TCP 的工作原理

下面小编就带你们了解 TCP 的工作原理是啥？

由前面的知识我们学习到 TCP 有三次握手。

TCP 的三次握手的示意图：

具体的含义理解可以这样看：

1、第一次握手

客户端想服务器发送一个 SYN 标志位为1的包，以及初始序号X，包装在包的头的序列号字段里。

客户端进入 SYN_SEND 状态，等待服务器端的确认。

2、第二次握手

服务器发回 ACK（确认包），即将SYN和ACK标志位都命名为1，同时将序列号修改为X+1。

同时自己也发送了一个包，SYN包，序列号（seq =Y），即 SYN +ACK 包。

此时服务器进入 SYN_RECV 状态。

3、第三次握手

客户端接收到服务器发送过来的（ACK+SYN）包,SYN 标志位为0。ACK 标志位为1。

同时把服务器发过来的 ACK 包序列号字段+1并放在包中，发给服务器即 ACK=Y+1。

通俗解释：

是不是觉得还是很难懂啊，那下面就给你举个例子。

首先我们假设 A和B 是本次进行通信的双方。 而发一次信息就代表着一次握手。

• 第一次握手: A 给 B 发微信语音聊天，在吗？能听到我讲话吗？
• 第二次握手：B 收到了 A 发来的微信语音通话，然后对A说：嗯，人在的，我能听见你说的话，你能听得见我说话吗，有什么事情？
• 第三次握手： A 收到了 B 回复回来的信息语音，我想问你一件事？

然后就开始愉快的聊天了。

两次握手是否可以？

那我们接下来探究 两次握手可不可以？

• 第一次握手之后： 服务器端B 可以接收到客户端A发来来的信息，但是对于客户端A 来说，它并不能确定自己发送的消息有没有成功。
• 第二次握手之后： 服务端B 向客户端A 发送的报文信息，服务器端B可以认为我发送的消息成功了。
• 如果现在没有第三次握手的话，服务器端B 在进行第二次握手之后，会认为我们的连接时成功的。

但是对于，客户端A 呢？并不能保证一定能接收到服务器端B发来的信息吧，如果客户端A没接受到服务器端发来的信息呢？

客户端就会认为我们之间的通信没有建立起来。 这样的通信过程显然是不成功的。

如果存在大量的这种情况发生的话，服务器B 会发生崩溃的。

看样子仅仅两次握手是不行的，完成不了 TCP 的通信工作原理。

两次不行，那四次呢？

四次握手行不行？

我们根据上面的 TCP 通信原理可知道，经过三次握手之后，客户端A 和服务器端B 都可以确认之前他们的所发送的消息，各自都能收到且报文也都成功发送给对方了。

依据上面那个结论可知道，你是四次握手还是五次握手，都是徒劳的。因为经过“三次握手”之后，把该做的事情都做完了。

结论

TCP 的三次握手是经典，计算机上的通信协议也都依据于 TCP 的三次握手和四次挥手。

因为计算机应用直接的通信依据于 HTTP 协议，而 HTTP 实质上是依靠 TCP 协议完成的，这个知识在前面说过。从而形成了：

• TCP 只能是三次握手，不能是两次，也不能是四次。
• 少于三次握手，不能保证是否建立了通信连接；
• 多于三次握手，都是徒劳和浪费的。

我们看出经过三次握手之后，我们可以得出下面的结论：

• A 可以给B发送消息了，同时A也能接受到B发来的信息；
• 与此同时对于B而言，B也可以给A发送消息，同时B也能接收到A发来的消息。

在这里小编整理了一份TPC文档 ，希望对大家有所帮助

由于篇幅限制小编只展示部分目录内容