TCP/IP（五）传输层之细说TCP的三次握手和四次挥手

阅读目录(Content)

• 1、运输层概述
• 1.一、运输层简介
• 1.二、端口
• 1.三、熟知端口、登记端口、客户端端口
• 2、UDP协议
• 　　2.一、UDP概述
• 　　2.二、特色　
• 　　2.三、UDP报文格式
• 　　2.四、使用UDP协议的例子
• 3、TCP协议
• 3.一、TCP协议概述
• 3.二、TCP协议功能　
• 3.三、TCP报文结构
• 3.四、面向链接（三次握手）
•  3.五、同时打开链接请求
• 3.六、可靠传输
• 3.七、流量控制
• 3.八、堵塞控制
• 3.九、TCP释放链接（四次挥手）
• 3.十、同时关闭链接

前言

　　这一篇我将介绍的是你们面试常常被会问到的，三次握手四次挥手的过程。之前我听到这个是什么意思呀？听的我一脸蒙逼，可是学习以后就原来就那么回事！

回到顶部(go to top)

1、运输层概述

1.一、运输层简介

　　这一层的功能也挺简单的，运输层提供应用层提供端到端通讯服务，通俗的讲，两个主机通信，也就是应用层上的进程之间的通讯，也就是转换为进程和进程之间的通讯了，咱们以前学到网络层，

　　IP协议能将分组准确的发送到目的主机，可是停留在网络层，并不知道要怎么交给咱们的主机应用进程，经过前面的学习，咱们学习有mac地址，经过mac地址能找到同一个网络下主机，有IP地址，

　　经过ip地址能找到不一样网络下的网络，结合mac地址就能找到对应主机，那么怎么找到主机应用进程呢，确定也有一个东西来标识它，那就是咱们常说的端口了。

1.二、端口

　　端口，占有16位，其大小也就有65536个，是从0~65535.也就是一台计算机有65535个端口，主机之间的通信，也就是应用进程之间的通信，都要依靠端口，一个进程对应一个端口，

　　进程A和进程B通讯，进程A分到的端口为60000，进程B分到的端口为60001，进程A经过端口60000发送数据给进程B，就知道要交给60001端口，也就到了进程B中 ，这样就达到了通讯的目的。

1.三、熟知端口、登记端口、客户端端口

　　1）熟知端口：0-1023， 也就是一些固定的端口号，好比http使用的80端口，意思就是在访问网址时，咱们访问服务器的端口就是80，而后服务器那边传网页的数据给咱们。

　　2）登记端口：1024-49151，好比微软开发了一个系统应用，该应用在通信或使用时，须要使用到xxx端口，那么就要去登记一下这个端口，以避免有别人公司的应用使用同一个端口号，

　　　　　　　　例如，windows系统中的3389端口，就是用来实现远程链接的，就固定了这台计算机若是要使用远程链接服务，就打开3389端口，别人就能使用远程链接连你了，默认是不打开的。

　　3）客户端端口：49152-65535，通常咱们使用某个软件，好比QQ，等其余服务，随机拿这个范围内的端口，而不是去拿前面哪些固定的，拿到等通信结束后，就会释放该端口。

知道了端口是什么？运输层具体作了什么事情呢？运输层就是将两个端口连起来通讯的介质，否则光知道两个端口有什么用，怎么通讯的，仍是要靠运输层来作这个事情，其中重要的就是靠两个协议，UDP和TCP协议。

回到顶部(go to top)

2、UDP协议

　　2.一、UDP概述

　　　　UDP:User Datagram Protocol 用户数据报协议

　　　　

　　2.二、特色　

　　　　无链接、不可靠

　　　　无链接：意思就是在通信以前不须要创建链接，直接传输数据。

　　　　不可靠：是将数据报的分组从一台主机发送到另外一台主机，但并不保证数据报可以到达另外一端，任何须须的可靠性都由应用程序提供。在 UDP 状况下，虽然能够确保发送消息的大小，

　　　　　　　　却不能保证消息必定会达到目的端。没有超时和重传功能，当 UDP 数据封装到 IP 数据报传输时，若是丢失，会发送一个 ICMP 差错报文给源主机。即便出现网络阻塞状况，

　　　　　　　　UDP 也没法进行流量控制。此外，传输途中即便出现丢包，UDP 也不负责重发，甚至当出现包的到达顺序杂乱也没有纠正的功能。

　　2.三、UDP报文格式

　　　　UDP在IP报文中的位置如图所示：

　　　　

　　　　UDP报文格式如图所示：

　　　　

　　　　1）UDP首部　　

　　　　　　源端口号：占16位，源主机的应用进程所使用的端口号

　　　　　　目标端口号：占16位，目标主机的应用进程所使用的端口号，也就是咱们须要通讯的目标进程

　　　　　　UDP（包）报长度：UDP用户数据报的长度，数据部分+UDP首部之和为UDP报长度。

　　　　　　检验和：检验和是为了提供可靠的 UDP 首部和数据而设计，这里不要和上面的不可靠传输搞混淆了，这里提供可靠的UDP首部，是由于一个进程可能接受多个进程过来的报文，那么如何区分他们呢，

　　　　　　　　　　就是经过5个东西来进行区分的， “源 IP 地址”、“目的 IP 地址”、“协议号”、“源端口号”、“目标端口号”的，这个检测可靠，是检测接受哪一个正确的报文，也就是说是哪一个报文要进这个端口。那个不可靠，

　　　　　　　　　　说的是这个报文可能丢失，可能其中数据损坏了咱们不关心，可是这些的前提是，你得传输到正确的目的地去，否则乱出乱发数据报，岂不是乱套了。

　　　　2）UDP伪首部

　　　　　　就是拿到IP层的一些数据，由于要进行检验和，就必需要有这些数据。其中检验的算法跟IP层中检验首部的办法是同样的。

　　　　　　分析：

　　　　　　　　

　　　　　一个目标进程中，其中的报文，目标端口，目标ip地址确定都是同样的，可是源IP地址和源端口就可能不同，这就说明了不一样源而同一目的地的报文会定位到同一队列。

　　　　　　这跟接下来咱们要讨论的TCP不同，由于UDP是无链接的，你们都是用这一条通道，因此其队列中就会出现上面所说的这样的状况。

　　2.四、使用UDP协议的例子

　　　　　　在选择使用协议的时候，选择UDP必需要谨慎。在网络质量使人十分不满意的环境下，UDP协议数据包丢失会比较严重。可是因为UDP的特性：它不属于链接型协议，于是具备资源消耗小，

　　　　处理速度快的优势，因此一般音频、视频和普通数据在传送时使用UDP较多，由于它们即便偶尔丢失一两个数据包，也不会对接收结果产生太大影响。好比咱们聊天用的ICQ和QQ就是使用的UDP协议。

　　　　1）应用层协议中DNS，也就是根据域名解析ip地址的一个协议，他使用的就是UDP

　　　　2）DHCP,这个是给各电脑分配ip地址的协议，其中用的也是UDP协议

　　　　3）IGMP，咱们说的多播，也就是使用的UDP，在多媒体教师，老师拿笔记本讲课，咱们在下面经过各自的电脑看到老师的画面，这就是经过UDP传输数据，因此会出现有的同窗卡，

　　　　　　有的同窗很流畅，就是由于其不可靠传输，可是卡一下，对接下来的观看并无什么映像。

回到顶部(go to top)

3、TCP协议

3.一、TCP协议概述

　　百度上说：

　　　　

　　TCP协议是面向链接的、可靠传输、有流量控制，拥塞控制，面向字节流传输等不少优势的协议。其最终功能和UDP同样，在端和端之间进行通讯，可是和UDP的区别仍是很大的。

3.二、TCP协议功能　

　　1）当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）一般受该计算机链接的网络的数据链路层的最大传送单元（MTU）限制。

　　　　以后TCP把数据包传给IP层，由它来经过网络将包传送给接收端实体的TCP层。
　　2）TCP为了保证报文传输的可靠，就给每一个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。而后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；

　　　　若是发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。
　　　　　　在数据正确性与合法性上，TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和；同时可使用md5认证对数据进行加密。
　　　　　　在保证可靠性上，采用超时重传和捎带确认机制。
　　　　　　在流量控制上，采用滑动窗口[1] 协议，协议中规定，对于窗口内未经确认的分组须要重传。
　　3）在拥塞控制上，采用广受好评的TCP拥塞控制算法（也称AIMD算法）。该算法主要包括三个主要部分：1）加性增、乘性减；2）慢启动；3）对超时事件作出反应。

3.三、TCP报文结构

　　

　　1）源端口号

　　2）目标端口号

　　3）序列号：由于在TCP是面向字节流的，他会将报文都分红一个个字节，给每一个字节进行序号编写，好比一个报文有900个字节组成，那么就会编成1-900个序号，而后分几部分来进行传输，

　　　　　　　　好比第一次传，序列号就是1，传了50个字节， 那么第二次传，序列号就为51，因此序列号就是传输的数据的第一个字节相对全部的字节的位置。

　　4）确认应答：如刚说的例子，第一次传了50个字节给对方，对方也会回应你，其中带有确认应答，就是告诉你下一次要传第51个字节来了，因此这个确认应答就是告诉对方要传第多少个字节了

　　5）首部长度：就是首部的长度，

　　6）保留：给之后有须要在用，这个保留的位置放的东西是跟控制位相似的

　　7）控制位：目前有的控制位为6个

　　　　URG:紧急，当URG为1时，表名紧急指针字段有效，标识该报文是一个紧急报文，传送到目标主机后，不用排队，应该让该报文尽可能往下排，让其早点让应用程序给接受。

　　　　ACK:确认，当ACK为1时，确认序号才有效。当ACK为0时，　　　　确认序号没用

　　　　PSH：推送，当为1时，当遇到此报文时，会减小数据向上交付，原本想应用进程交付数据是要等到必定的缓存大小才发送的，可是遇到它，就不用在等足够多的数据才向上交付，

　　　　　　　　而是让应用进程早点拿到此报文，这个要和紧急分清楚，紧急是插队，可是提交缓存大小的数据不变，这个推送就要排队，可是遇到他的时候，会减小交付的缓存数据，提早交付。

　　　　RST:复位，报文遇到很严重的差错时，好比TCP链接出错等，会将RST置为1，而后释放链接，所有从新来过。

　　　　SYN：同步，在进行链接的时候，也就是三次握手时用获得，下面会具体讲到，配合ACK一块儿使用

　　　　FIN：终止，在释放链接时，也就是四次挥手时用的。

　　8）窗口：指发送报文段一方的接受窗口大小，用来控制对方发送的数据量(从确认号开始，容许对方发送的数据量)。也就是后面须要讲的滑动窗口的窗口大小

　　9）检验和：检验首部和数据这两部分，和UDP同样，须要拿到伪首部中的数据来帮助检测

　　10）选项：长度可变，介绍一种选项，最大报文段长度，MSS。 可以告诉对方TCP，个人缓存能接受报文段的数据字段的最大长度是MSS个字节。若是没有使用选项，那么首部固定是20个字节。

　　11）填充：就是为了让其成为整数个字节

3.四、面向链接（三次握手）

　　面向链接(三次握手)：在通讯以前，会先经过三次握手的机制来确认两端口之间的链接是否可用。而UDP不须要确认是否可用，直接传。

　　三次握手机制：

　　　　　　　

　　一开始客户端和服务端都是关闭状态，可是在某个时刻，客户端须要和服务端进行通讯，此时双方都会各自准备好端口，服务器段的端口会处于监听状态，等待客户端的链接。

　　客户端可会知道本身的端口号，和目的进程的端口号，这样才能发起请求。

　　第一次握手：客户端想与服务器进行链接了，因此状态变为主动打开，同时发送一个链接请求报文给服务器段SYN=1，而且会携带x个字节过去。

　　　　　　　　发送完请求链接报文后，客户端的状态就变为了SYN_SENT，能够说这个状态是等待发送确认(为了发送第三次握手时的确认包)

　　第二次握手：服务端接收到链接请求报文后，从LSTTEN状态变为被动打开状态，而后给客户端返回一个报文。这个报文有两层意思，一是确认报文，而能够达到告诉客户端，我也打开链接了。

　　　　　　　　发完后，变为SYN_RCVD状态(也能够说是等待接受确认状态，接受客户端发过来的确认包)

　　第三次握手：客户端获得服务器端的确认和知道服务器端也已经准备好了链接后，还会发一个确认报文到服务器端，告诉服务器端，我接到了你发送的报文，接下来就让咱们两个进行链接了。

　　　　　　　　客户端发送完确认报文后，进入ESTABLISHED，而服务器接到了，也变为ESTABLISHED。

 3.五、同时打开链接请求

　　正常状况下，通讯一方请求创建链接，另外一方响应该请求，可是若是出现，通讯双方同时请求创建链接时，则链接创建过程并非三次握手过程，并且这种状况的链接也只有一条，并不会创建两条链接。

　　同时打开链接时，两边几乎同时发送 SYN，并进入 SYN_SENT 状态，当每一端收到 SYN 时，状态变为 SYN_RCVD，同时双方都再发 SYN 和 ACK 做为对收到的 SYN 进行确认应答。

　　当双方都收到 SYN 及相应的 ACK 时，状态变为 ESTABLISHED 

　　

3.六、可靠传输

　经过1）数据编号和积累确认 2）以字节为单位的滑动窗口 3）超时重传时间 4）快速重传 这四个方面来达到可靠传输的目的。

　　1）、数据编号：将每一个字节进行编号，有900个字节，就从1到900进行编号

　　　　 积累确认：服务器端不是接收到一个字节就发一个确认，那样效率过低，而是当接收到4，5个时，在发送一个确认，那么在以前的确认以前的数据就算发送成功了的。

　　2）滑动窗口：这个跟在数据链路层讲个滑动窗口同样。每次能发送的数据是在此窗口中的，接到了多少数据，就日后滑多少数据

　　3）超时重传时间：这个也在链路层讲过，若是等待一段时间后，还没接收到确认报文，那么就从新传

　　4）快速重传：在滑动窗口中的应用，好比传了1234 6到服务器端，老办法是在4以后的全部数据度要从新传，而这个快速重传就只须要等待传了5这个序号，就能够继续往下接收数据了。

3.七、流量控制

　　在传输层中，有接受缓存和发送缓存这两个东西的存在，因此每次发送数据过去另外一端时，都会把这些数据给带过去，让对方知道本身的这两个缓存的大小，而后来合理的设置本身的发送窗口的大小，

　　若是对方的缓存快满了，对方在传送数据过来的时候，就会告诉本身，少发一点数据过来，本身就设置滑动窗口小一点，让对方有缓冲的机会，而不会致使缓存溢出，不让本身的报文被丢弃。

3.八、堵塞控制

　　其实跟流量控制差很少，可是站的角度更大，此时既考虑了对方接收不过来，缓存太多溢出致使，又考虑在线路中，线路上的传输速率就那么大，可是有不少人同时用，发送的数据太多，就会使线路发现拥塞，

　　也就是路由器可能转发不过来，致使大量数据丢失，这两个问题。因此拥塞控制这个解决方案，大概意思就是当检测到有网络拥塞时，就会让本身的滑动窗口变小，但具体是怎么变化的，就是根据算法来算了，

　　　　发送窗口的上限值 = Min[rwnd，cwnd]    

　　　　rwnd：接受窗口，根据接受缓存，而定的接受窗口，接收缓存还有不少，那么接收窗口就大

　　　　cwnd：拥塞窗口，根据线路中的拥塞情况来决定，线路中不拥塞，那么此窗口就大，

　　　　发送窗口是取两个中较小值。这个仍是能够理解的。

　　慢启动算法、快速恢复算法、结合来达到对拥塞进行控制的。

3.九、TCP释放链接（四次挥手）

　　通讯完成后，链接就会被释放，经过四次挥手机制来完成这个事情。

　　

　　

　　第一次挥手：从ESTABLISHED变为主动关闭状态，客户端主动发送释放链接请求给服务器端，FIN=1。发送完以后就变为FIN_WAIT_1状态，这个状态能够说是等待确认状态。

　　第二次挥手：服务器接收到客户端发来的释放链接请求后，状态变为CLOSE_WAIT，而后发送确认报文给客户端，告诉他我接收到了你的请求。为何变为CLOSE_WAIT，缘由是是客户端发送的释放链接请求，

　　　　　　　　可能本身这端还有数据没有发送完呢，因此这个时候整个TCP链接的状态就变为了半关闭状态。服务器端还能发送数据，而且客户端也能接收数据，可是客户端不能在发送数据了，只可以发送确认报文。

　　　　　　　　客户端接到服务器的确认报文后，就进入了FIN_WAIT_2状态。也能够说这是等待服务器释放链接状态。

　　第三次挥手：服务器端全部的数据度发送完了，认为能够关闭链接了，状态变为被动关闭，因此向客户端发送释放链接报文，发完以后本身变为LAST_WAIT状态，也就是等待客户端确认状态

　　第四次挥手：客户端接到释放链接报文后，发送一个确认报文，而后本身变为TIME_WAIT,而不是立马关闭，由于客户端发送的确认报文可能会丢失，丢失的话服务器就会重传一个FIN，也就是释放链接报文，

　　　　　　　　这个时候客户端必须还没关闭。 当服务器接受到确认报文后，服务器就进入CLOSE状态，也就是关闭了。可是因为上面说的这个缘由，客户端必须等待必定的时间才可以进入CLOSE状态。

3.十、同时关闭链接

　　正常状况下，通讯一方请求链接关闭，另外一方响应链接关闭请求，而且被动关闭链接。可是若出现同时关闭链接请求时，通讯双方均从 ESTABLISHED 状态转换为 FIN_WAIT_1 状态。

　　任意一方收到对方发来的 FIN 报文段后，其状态均由 FIN_WAIT_1转变到 CLOSING 状态，并发送最后的 ACK 数据段。当收到最后的 ACK 数据段后，状态转变化 TIME_WAIT，

　　在等待 2MSL 时间后进入到 CLOSED 状态，最终释放整个 TCP 传输链接。其过程入下：

　　

总结：通常须要保证数据可靠时，都会使用tcp协议：http协议进行网站的访问时，使用的就是tcp。