通信的真正端点并不是主机而是主机中的进程，也就是说，端到端的通信是应用进程之间的通信
传输层主要就干一件事：建立端到端的连接
比如浏览网页，软件聊天，以及收看视频都是通过这两种协议来进行数据传输的
TCP和UDP都工作在传输层，它们的目标都是在程序之间传输数据
而数据可以是文本文件，可以是视频，可以是图片
对于tcp协议和udp协议来说都是一堆二进制数，并没有多大区别。那TCP和UDP之间的区别到底是什么？
最大的区别是一个基于连接（tcp），一个基于非连接（udp）
举个简单的例子：如果把人与人之间的通信比喻成进程与进程的通信，
我们基本有两种方式：第一种方式是写信，第二种是打电话
这两种方式的最大区别是什么，就是写信（udp）存在以下未知数
1.信寄出去之后对方是否能收到
2.以及收到的信内容是否完整
3.先后寄出去的信，是否按发送顺序接受
4.甚至你填写收信人和收信地址是否存在，你都无法确认
而打电话（tcp）则不同
从拨打电话——对方接通——互相通话——结束挂断
这一系列流程都能得到及时的反馈，并能确认对方准确的接收到
TCP是如何保证以上过程的，有三个关键步骤：三次握手，传输确认，四次挥手
三次握手是建立连接的过程
三次握手：
机长（客户端）：成都成都，我是四川8633
李现（服务端）：四川8633，请讲
机长（客户端）：我现在有点故障，申请下降高度
1. 当客户端向服务端发起连接时，会先发一包连接请求数据，过去询问一下，能否建立连接，这包数据称为SYN（同步）包（sin包：成都成都，我是四川8633）
只是把SYN开启（将SYN置1）是不够的，报文里还有一个重要字段Sequence序号
PS：为什么还需要sequence序号呢？
因为应用程序（客户端）可能连续发送多个序号给服务器（服务端），这样服务器就起码有依据可以判断哪些是累赘信息，而且这个sequence序号是随机生成的，作为初始值来进行后续判断依据，这样就更加保证了通道的唯一性。
2. 假设上述例子的序号为8633，当服务器收到SYN以后就要开始响应了，这个时候服务器会在TCP报文中把SYN和ACK（确认） 开启（就是全部置为1），SYN + ACK合起来就是确认同步的意思。那么服务器也生成自己的序号，假设这里自己的序号为：303（随机生成的），这样还不够还要加上确认号，这个确认号就是根据对方的序号+1得到的
这样客户端在收到号码后-1就知道是不是自己发送的TCP报文了，最后客户端还需要确认，因为如果不确认的话（相当于两次握手），服务器不知道自己发送出去“确认同步”是否被接受。于是必须再发送一次TCP报文来使连接正式建立。
3. 这个时候客户端会把ACK开启（ACK置为1），并且序号是服务端确认号（8633+1）,确认号上根据对方的序号+1（303+1）
那么问题来了，每次发来的SYN服务器都要记住它的序号，并且新生成自己需要记住的序号，那服务器就需要挂起非常多的资源，如果有黑客借此不断发送SYN又不进行下一步，就会导致服务器原地崩溃也就是典型的DDoS攻击,因此服务器干脆不保存自己的序号，而是根据服务器的IP地址和端口号等私有信息进行算法的运算得到序号
三次握手之后就建立了连接，这个时候可以发送HTTP请求了
假设服务器内容响应完毕了，各自可能就会发起关闭连接的要求了，这个过程就是四次挥手，注意客户端和服务端都能主动发起关闭请求。
1. 假设这里是客户端主动发起关闭请求，这个时候客户端会在报文中同时开始FIN（结束）和ACK两个控制位，这里就是为了结束会话，
因为在发送HTTP请求和响应的时候序号和确认号被不断递增，因此这里就不再用固定数字来表示序号和确认号了
2. 此时一般服务端会先发送一个ACK来进行确认，（然后套路和之前一样，自己的序号用对方的确认号，自己的确认号在对方的序号上+1），
虽然发送了TCP报文，但是此时的客户端并未正式关闭通道，因为服务端那边可能还有需要发送的数据，
3. 等服务端发送完数据以后会再发送一个FIN + ACK 来进行最后的确认，此时序号和确认号不需要改变（因为没有一来一回，只是多了一个控制位FIN来进行确认结束步骤而已）
4. 最后客户端得到最终的结束确认以后，会发送ACK来进行确认。此时自己的序号需要用对方的确认号，确认号是对方的序号+1
其实中间的ACK和FIN + ACK两步就足以证明为什么要4次挥手，因为可能还存在未发送完毕的数据