a.OSI7层模型
b.TCP/IP参考模型
c.TCP/IP传输层协议
d.tcp连接3次握手,断开4次握手
a.OSI7层模型
OSI(开放式系统互联)
物联网传话表应用
物理层 设备的比特流传输 网卡
数据链路层 用MAC地址访问媒介,错误检测、修正 交换机
网络层 提供逻辑寻址 路由器
传输层 可靠和不可靠的传输 TCP/UDP
会话层 对应会话管理、同步 操作系统、应用读取
表示层 数据表现形式,加密等 ASCII,JPEG
应用层 用户接口 http、telnet
注意:下层为上层提供服务,同层次之间使用相同协议,每层协议之间相互独立
b.TCP/IP协议参考模型
网络接口层(物理、数据链路)
互联网层
传输层
应用层(应用、表示、会话)
TCP/IP和OSI模型比较
相同点
1.都是以协议栈为基础
2.彼此协议相互独立
3.下层为上层提供服务
不同点
1.OSI是先有模型,TCP/IP是先有协议,后有模型
2.OSI适用于各种协议,TCP/IP只适用于TCP/IP网络
3.层次数量不一样
c.TCP/IP体系同传输层
UDP:用户数据报协议
面向无连接的服务
不需要事先建立连接
每个报文携带完整目的地址
不保证传输可靠性
TCP:传输控制协议
面向连接的服务
先建立连接,在传输数据,再断开
数据传输过程中不需要携带目的地址
保证数据传输可靠性
常用的熟知端口号
应用程序 | FTP | TFTP | TELNET | SMTP | DNS | HTTP | SSH | MYSQL |
---|---|---|---|---|---|---|---|---|
熟知端口 | 21,20 | 69 | 23 | 25 | 53 | 80 | 22 | 3306 |
传输层协议 | TCP | UDP | TCP | TCP | UDP | TCP |
d.TCP连接和断开挥手
1、三次握手
为什么TCP客户端最后还要发送一次确认呢?
一句话,主要防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。
如果使用的是两次握手建立连接,假设有这样一种场景,客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。
如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。
置位概念:根据TCP的包头字段,存在3个重要的标识ACK、SYN、FIN
FIN:序号
ACK:表示验证字段(确认号)
SYN:位数置1,表示建立TCP连接
FIN:位数置1,表示断开TCP连接
三次握手过程说明:
1、由客户端发送建立TCP连接的请求报文,其中报文中包含seq序列号,是由发送端随机生成的,并且将报文中的SYN字段置为1,表示需要建立TCP连接。(SYN=1,seq=x,x为随机生成数值)
2、由服务端回复客户端发送的TCP连接请求报文,其中包含seq序列号,是由回复端随机生成的,并且将SYN置为1,而且会产生ACK字段,ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP建立请求已得到验证。(SYN=1,ACK=x+1,seq=y,y为随机生成数值)这里的ack加1可以理解为是确认和谁建立连接。
3、客户端收到服务端发送的TCP建立验证请求后,会使自己的序列号加1表示,并且再次回复ACK验证请求,在服务端发过来的seq上加1进行回复。(SYN=1,ACK=y+1,seq=x+1)
2、四次挥手
四次挥手过程说明:
1、客户端发送断开TCP连接请求的报文,其中报文中包含seq序列号,是由发送端随机生成的,并且还将报文中的FIN字段置为1,表示需要断开TCP连接。(FIN=1,seq=x,x由客户端随机生成)2、服务端会回复客户端发送的TCP断开请求报文,其包含seq序列号,是由回复端随机生成的,而且会产生ACK字段,ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP断开请求已经得到验证。(FIN=1,ACK=x+1,seq=y,y由服务端随机生成)
3、服务端在回复完客户端的TCP断开请求后,不会马上进行TCP连接的断开,服务端会先确保断开前,所有传输到A的数据是否已经传输完毕,一旦确认传输数据完毕,就会将回复报文的FIN字段置1,并且产生随机seq序列号。(FIN=1,ACK=x+1,seq=z,z由服务端随机生成)
4、客户端收到服务端的TCP断开请求后,会回复服务端的断开请求,包含随机生成的seq字段和ACK字段,ACK字段会在服务端的TCP断开请求的seq基础上加1,从而完成服务端请求的验证回复。(FIN=1,ACK=z+1,seq=h,h为客户端随机生成)
至此TCP断开的4次挥手过程完毕
3、11种状态
1、一开始,建立连接之前服务器和客户端的状态都为CLOSED;
2、服务器创建socket后开始监听,变为LISTEN状态;
3、客户端请求建立连接,向服务器发送SYN报文,客户端的状态变味SYN_SENT;
4、服务器收到客户端的报文后向客户端发送ACK和SYN报文,此时服务器的状态变为SYN_RCVD;
5、然后,客户端收到ACK、SYN,就向服务器发送ACK,客户端状态变为ESTABLISHED;
6、服务器端收到客户端的ACK后变为ESTABLISHED。此时3次握手完成,连接建立!
由于TCP连接是全双工的,断开连接会比建立连接麻烦一点点。
1、客户端先向服务器发送FIN报文,请求断开连接,其状态变为FIN_WAIT1;
2、服务器收到FIN后向客户端发送ACK,服务器的状态围边CLOSE_WAIT;
3、客户端收到ACK后就进入FIN_WAIT2状态,此时连接已经断开了一半了。如果服务器还有数据要发送给客户端,就会继续发送;
4、直到发完数据,就会发送FIN报文,此时服务器进入LAST_ACK状态;
5、客户端收到服务器的FIN后,马上发送ACK给服务器,此时客户端进入TIME_WAIT状态;
6、再过了2MSL长的时间后进入CLOSED状态。服务器收到客户端的ACK就进入CLOSED状态。
至此,还有一个状态没有出来:CLOSING状态。
CLOSING状态表示:
客户端发送了FIN,但是没有收到服务器的ACK,却收到了服务器的FIN,这种情况发生在服务器发送的ACK丢包的时候,因为网络传输有时会有意外。
LISTEN:等待从任何远端TCP 和端口的连接请求。
SYN_SENT:发送完一个连接请求后等待一个匹配的连接请求。
SYN_RECEIVED:发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。
ESTABLISHED:表示一个打开的连接,接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。
FIN_WAIT_1:等待远端TCP 的连接终止请求,或者等待之前发送的连接终止请求的确认。
FIN_WAIT_2:等待远端TCP 的连接终止请求。
CLOSE_WAIT:等待本地用户的连接终止请求。
CLOSING:等待远端TCP 的连接终止请求确认。
LAST_ACK:等待先前发送给远端TCP 的连接终止请求的确认(包括它字节的连接终止请求的确认)
TIME_WAIT:等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。
TIME_WAIT 两个存在的理由:
1.可靠的实现tcp全双工连接的终止;
2.允许老的重复分节在网络中消逝。
CLOSED:不在连接状态(这是为方便描述假想的状态,实际不存在)