TCP学习

TCP和UDP

OSI七层网络协议

OSI将通讯协议中必要的功能分成了七层，每个分层接收下一层的服务，并为上一层提供服务，上层和下层之间的交互叫做接口，同层之间的交互所遵循的约定叫做协议

物理层

--硬件
负责数据传输的硬件，相当于以太网或电话线等物理层的设备

数据链路层

--网络接口层
网络接口层利用以太网中的数据链路层进行通信，因此属于接口层，也就是说，把它当做让NIC起作用的驱动程序也无妨。驱动程序是在操作系统与硬件之间起桥梁的软件。

网络层

--互联网层
互联网层使用IP协议，相当于第三层的网络层，ip协议基于ip地址转发分包数据

传输层

传输层最主要的的功能就是让应用程序之间实现通讯，计算机内部同一时间运行多个程序，需要分清哪些程序与哪些程序在进行通讯。
ip首部有个协议字段，用来标记上一层采用的是那一种传输层协议，根据这个字段就可以判断数据是tcp还是udp内容
TCP --一种面向有连接的传输层协议，可以保证两端通信主机之间的通信可达，能够正确处理在传输过程中丢包，传输顺序乱掉等异常情况，能够有效利用带宽，缓解网络拥堵。
为了建立连接，需要至少七次 的发包收包，导致网络流量的浪费，为了提高网络利用率，TCP协议中定义了各种各样复杂的规范，因此不利于视频会议等场合使用。
UDP -- 区别于tcp，是一种面向无连接的传输层协议，不会关注对端是否真的收到传递过去的数据，如果需要检查对端是否收到分组数据包，或者对端是否连接到网络，需要在应用程序中实现，常用于分组数据较少或多播，广播通信以及视频通信等多媒体领域。

会话层、表示层、应用层

这三层都集中在应用程序中实现，这些有时是一个单一的程序实现，有时是多个程序实现，

上图画出了 TCP 建立连接的过程。假定主机 A 是 TCP 客户端，B是服务端。最初两端的 TCP 进程都处于 CLOSED 状态。图中在主机下面的是 TCP进程所处的状态。A 是主动打开连接，B 是被动打开连接。

三次握手过程分析：
（1）首先A向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号 seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，A进入SYN-SENT状态。【备注：序号指的是 TCP 报文段首部20字节里的序号，TCP 连接传送的字节流的每一个字节都按顺序编号，具体可以看看 TCP 可靠传输实现的原理】
（2）B收到请求后，向A发送确认。在确认报文段中把SYN和ACK位都置为1，确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时B进入SYN-RCVD状态。
（3）A收到B的确认后，还要向B给出确认。确认报文段的ACK置为1，确认号ack=y+1，而自己的序号seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED 状态，当B收到A的确认后，也会进入 ESTABLISHED 状态。

以上给出的连接建立过程就是常说的TCP三次握手。

2.1 为什么需要三次握手过程（面试经常问）

为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。
　　所谓已失效的连接请求报文段是这样产生的。A发送连接请求，但因连接请求报文丢失而未收到确认，于是A重发一次连接请求，成功后建立了连接。数据传输完毕后就释放了连接。现在假定A发出的第一个请求报文段并未丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误以为A又发了一次新的连接请求，于是向A发出确认报文段，同意建立连接。假如不采用三次握手，那么只要B发出确认，新的连接就建立了。
　　由于A并未发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据，因此白白浪费了许多资源。
　　采用TCP三次握手的方法可以防止上述现象发生。例如在刚才的情况下，由于A不会向B的确认发出确认，连接就不会建立。

2.2 如果在TCP第三次握手中的报文段丢失了会发生什么情况?

Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误。

四次握手（两个二次握手）过程分析：

数据传输结束后，通信的双方都可以释放连接，并停止发送数据。假设现在客户端和服务端都处于ESTABLISHED状态。

（1）客户端 A 的 TCP 进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭 TCP 连接。释放连接报文段中 FIN=1，序号为 seq=u，该序号等于前面已经传送过去的数据的最后一个字节的序号加1。这时，A进入 FIN—WAIT-1 (终止等待1)状态，等待 B 的确认。TCP 规定，FIN报文段即使不携带数据，也要消耗掉一个序号。这是 TCP 连接释放的第一次挥手。
（2）B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1，确认号为ack=u+1，其自己的序号为v，该序号等于B前面已经传送过的数据的最后一个字节的序号加1。然后B进入CLOSE—WAIT(关闭等待)状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了，但B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。

（3）A收到B的确认后，就进入了FIN—WAIT(终止等待2)状态，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这时B发出的链接释放报文段中，FIN=1，确认号还必须重复上次已发送过的确认号，即ack=u+1，序号seq=w，因为在半关闭状态B可能又发送了一些数据，因此该序号为半关闭状态发送的数据的最后一个字节的序号加1。这时B进入LAST—ACK(最后确认)状态，等待A的确认，这是TCP连接的第三次挥手。

（4）A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，确认号ack=w+1，而自己的序号seq=u+1，而后进入TIME—WAIT(时间等待)状态。这时候，TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态，时间MSL叫做最长报文寿命，RFC建议设为2分钟，因此从A进入TIME—WAIT状态后，要经过4分钟才能进入到CLOSED状态，而B只要收到了A的确认后，就进入了CLOSED状态。二者都进入CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。

3.1 为什么需要四次挥手
①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。
②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。

可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.

【备注】当客户端执行主动关闭并进入TIME—WAIT是正常的，服务端执行被动关闭，不会进入TIME—WAIT状态，这说明，如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

部分内容为摘抄其他网友的，如有侵权请联系我删除，谢谢