TCP/IP四层协议和TCP三次握手

OSI七层模型和TCP/IP四层模型

OSI：Open System Interconnection 开放系统互连。七层网络模型称为开放式网络互连参考模型；

TCP/IP：Transmission Control Protocol / Internet Protocol 传输控制协议/因特网互连协议。是最基本的Internet协议，由网络层的IP和传输层的TCP构成。

OSI七层模型	TCP/IP四层模型	对应网络协议
应用层	应用层	TFTP、FTP、NFS、WAIS
表示层		Telnet、SNMP
会话层		SMTP、DNS
传输层	传输层	TCP、UDP
网络层	网络层	IP、ICMP、ARP、RIP
数据链路层	网络接口层 (数据链路层)	FDDI、Ethernet
物理层		IEEE802.1、IEEE802.2到802.11

TCP/IP的四层模型（主流实现）

       应用层：应用程序间沟通的层，如简单电子邮件传输（SMTP）、文件传输协议（FTP）、网络远程访问协议（Telnet）等。

       传输层：在此层中，它提供了节点间的数据传送服务，如传输控制协议（TCP）、用户数据报协议（UDP）等，TCP和UDP给数据包加入传输数据并把它传输到下一层中，这一层负责传送确定数据已被送达并接收。

互连网络层：负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机（但不检查是否被正确接收），如网际协议（IP）。

        网络接口层：对实际的网络媒体的管理，定义如何使用实际网络（如Ethernet、Serial Line等）来传送数据。

OSI(Open System Interconnection)七层模型（参考模型，并未实现）

物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱 来进行传输,到达目的地后在转化为1、0，也就是我们常说的数模转换与模数转换）。这一层的数据叫做比特。 

数据链路层：定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。（交换机就工作在这一层）

网络层：在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加，而网络层正是管理这种连接的层。（路由器就工作在这一层、IP协议）

传输层：定义了一些传输数据的协议和端口号（WWW端口80等），如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议，与TCP特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种方式传输的）。 主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组。常常把这一层数据叫做段。 

会话层：通过传输层（端口号：传输端口与接收端口）建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名） 　　

表示层：可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机使用扩展二一十进制 交换码（EBCDIC），而另一台则使用美国信息交换标准码（ASCII）来表示相同的字符。如有必要，表示层会通过使用一种通格式来实现多种数据格式之间的转换。（多种机器间的转换）

应用层： 是最靠近用户的OSI层。这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务。（提供规范、HTTP协议）

UDP和TCP的区别

UDP(User Datagram Protocol):提供无连接的通信，不能保证数据包被发送到目标地址，典型的即时传输少量数据的应用程序通常使用UDP。

       TCP全双工的：面向连接的（三次握手） 面向字节流的，有拥塞控制(根据网络的好坏控制报文发送的速率)。面向连接的、可靠的、基于字节流的应用程序提供连接定向和可靠的通信。

1. TCP面向连接的传输控制协议，而UDP是没有面向连接的数据报服务；

2. TCP高可靠性，确保传输数据的正确性，不会出现丢失或乱序；UDP在传输数据前不建立连接，不对数据报进行检查与修改，无需等待对方的回答，所以会出现分组丢失，重复，乱序，应用程序需要负责传输可靠性方面的所有工作；

3. TCP对系统资源要求多，UDP对系统资源要求少；

4. UDP具有较好的实时性，工作效率较TCP高；

5. UDP的段结构比TCP段结构简单，因此网络开销小。

TCP报文

TCP三次握手和四次挥手过程

三次握手的详述：首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

位码即tcp标志位，有6种标示：SYN(synchronous建立联机) 、ACK(acknowledgement 确认) 、PSH(push传送) 、FIN(finish结束) 、RST(reset重置) 、URG(urgent紧急)、Sequence number(顺序号码) 、Acknowledge number(确认号码)

第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ACK=1,随机产生seq=7654321的包。

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ACK是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ACK=1，主机B收到  后确认seq值与ACK=1则连接建立成功。

TCP三次握手有哪些漏洞，有没有被攻击的可能，怎么被攻击？

答：是有漏洞的，主要是如果收到一个恶意攻击的ip一直请求连接，然后服务器会发送ack确认，但是永远等不到回复，就会导致服务器的NIC(网络适配器)，内存，cpu占用率超载，这种攻击方式叫做基于TCP半开回话的洪水攻击（SYN Flood）。

DDos攻击：

Step1：客户端向服务端发送连接请求数据包；

Step2：服务端向客户端回复连接请求数据包，然后服务器等待客户端发送tcp/ip连接的第三步数据包；

Step3：如果客户端不向服务端发送最后一个数据包，则服务器必须等待30s到2min的时间才能将连接关闭。

当大量的请求只进行到第二步的时候，而不进行第三步，服务器大量的资源都变成了等待第三个数据包，则造成DDos攻击。

预防DDos的方法：（没有根治的方法，除非不用TCP/IP连接）

• 严格限制对外开放的服务器的向外访问；
• 确保服务器的系统文件是最新版本，并及时更新系统补丁；
• 关闭不必要的服务；
• 限制同时打开SYN的半连接数目；
• 缩短SYN半连接的time out时间；
• 正确设置防火墙；
• 禁止对主机的非开放服务的访问；
• 限制特定IP短地址的访问；
• 启用防火墙的防DDos的属性.

为什么A还要发送一次确认呢？可以二次握手吗？

答：主要为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。如A发出连接请求，但因连接请求报文丢失而未收到确认，于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，A工发出了两个连接请求报文段，其中第一个丢失，第二个到达了B，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接，不采用三次握手，只要B发出确认，就建立新的连接了，此时A不理睬B的确认且不发送数据，则B一致等待A发送数据，浪费资源。

四次挥手

由Client或者server主动发起终端请求。假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

第一次挥手：A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。

第二次挥手：B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。

第三次挥手：A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。

第四次挥手：B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。

等待过程：A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。

A为什么等待2MSL，从TIME_WAIT到CLOSE？

在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

为什么连接的时候是三次握手，关闭的时候却是四次握手？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

服务器出现大量CLOSE_WAIT状态的原因

对方关闭socket连接，我方忙于读写，没有及时关闭连接（netstat命令查看服务器处于CLOSE_WAIT状态的个数）

1. 检查代码，特别是释放资源的代码
2. 检查配置，特别是处理请求的线程配置是否合理

TCP滑动窗口

可以参考解析TCP之滑动窗口(动画演示)

RTT：发送一个数据包到受到对应的ACK所花费的时间

RTO：重传时间间隔，需要根据RTT设计一个好的算法来计算