全网营销式网站,wordpress 新年插件,重庆正云环境网页制作,网站开发和c语言网络基础 这一个课程的笔记 相关文章 协议 Socket编程 高并发服务器实现 线程池 协议
一组规则, 数据传输和数据的解释的规则。
比如说依次发送文件的文件名, 文件的大小, 以及实际的文件, 这样规定发送一个文件的顺序以及发送的每一个部分的格式等可以算是一种协议
型协议 …网络基础 这一个课程的笔记 相关文章 协议 Socket编程 高并发服务器实现 线程池 协议
一组规则, 数据传输和数据的解释的规则。
比如说依次发送文件的文件名, 文件的大小, 以及实际的文件, 这样规定发送一个文件的顺序以及发送的每一个部分的格式等可以算是一种协议
型协议
传输层 常见协议有TCP/UDP协议。
应用层 常见的协议有HTTP协议FTP协议。
网络层 常见协议有IP协议、ICMP协议、IGMP协议。
网络接口层 常见协议有ARP协议、RARP协议。
TCP传输控制协议Transmission Control Protocol是一种面向连接的、可靠的、基于字节流的传输层通信协议。
UDP用户数据报协议User Datagram Protocol是OSI参考模型中一种无连接的传输层协议提供面向事务的简单不可靠信息传送服务。
HTTP超文本传输协议Hyper Text Transfer Protocol是互联网上应用最为广泛的一种网络协议。
FTP文件传输协议File Transfer Protocol
IP协议是因特网互联协议Internet Protocol
ICMP协议是Internet控制报文协议Internet Control Message Protocol它是TCP/IP协议族的一个子协议用于在IP主机、路由器之间传递控制消息。
IGMP协议是 Internet 组管理协议Internet Group Management Protocol是因特网协议家族中的一个组播协议。该协议运行在主机和组播路由器之间。
ARP协议是正向地址解析协议Address Resolution Protocol通过已知的IP寻找对应主机的MAC地址。
分层模型
OSI七层模型 OSI模型
物理层主要定义物理设备标准如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流就是由1、0转化为电流强弱来进行传输到达目的地后再转化为1、0也就是我们常说的数模转换与模数转换。这一层的数据叫做比特。数据链路层定义了如何让格式化数据以帧为单位进行传输以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正以确保数据的可靠传输。如串口通信中使用到的115200、8、N、1网络层在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加而网络层正是管理这种连接的层。传输层定义了一些传输数据的协议和端口号WWW端口80等如TCP传输控制协议传输效率低可靠性强用于传输可靠性要求高数据量大的数据UDP用户数据报协议与TCP特性恰恰相反用于传输可靠性要求不高数据量小的数据如QQ聊天数据就是通过这种方式传输的。 主要是将从下层接收的数据进行分段和传输到达目的地址后再进行重组。常常把这一层数据叫做段。会话层通过传输层(端口号传输端口与接收端口)建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求设备之间需要互相认识可以是IP也可以是MAC或者是主机名。表示层可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如PC程序与另一台计算机进行通信其中一台计算机使用扩展二一十进制交换码(EBCDIC)而另一台则使用美国信息交换标准码ASCII来表示相同的字符。如有必要表示层会通过使用一种通格式来实现多种数据格式之间的转换。应用层是最靠近用户的OSI层。这一层为用户的应用程序例如电子邮件、文件传输和终端仿真提供网络服务。 物数网传会表应 网网传应 TCP/IP四层模型
TCP/IP网络协议栈分为应用层Application、传输层Transport、网络层Network和链路层Link四层。如下图所示 TCP/IP模型 应用层: http ftp nfs ssh telnet 传输层: tcp udp 网络层: IP ICMP IGMP 链路层: 以太网帧协议 ARP 一般在应用开发过程中讨论最多的是TCP/IP模型。 通信过程
两台计算机通过TCP/IP协议通讯的过程如下所示 发送一个信息的时候首先会被应用层进行封装, 比如如果是一个文件可能使用FTP协议 之后是传输层, 网络层, 链路层依次增加他自己的协议 封装之后就可以发送到网络里面了 获取到信息以后反方向进行解封 数据没有封装是不能在网络里面传输的, 用户层协议是我们实际需要实现的
TCP/IP通信过程
上图对应两台计算机在同一网段中的情况如果两台计算机在不同的网段中那么数据从一台计算机到另一台计算机传输过程中要经过一个或多个路由器如下图所示 跨路由通信
链路层有以太网、令牌环网等标准链路层负责网卡设备的驱动、帧同步即从网线上检测到什么信号算作新帧的开始、冲突检测如果检测到冲突就自动重发、数据差错校验等工作。交换机是工作在链路层的网络设备可以在不同的链路层网络之间转发数据帧比如十兆以太网和百兆以太网之间、以太网和令牌环网之间由于不同链路层的帧格式不同交换机要将进来的数据包拆掉链路层首部重新封装之后再转发。
网络层的IP协议是构成Internet的基础。Internet上的主机通过IP地址来标识Inter-net上有大量路由器负责根据IP地址选择合适的路径转发数据包数据包从Internet上的源主机到目的主机往往要经过十多个路由器。路由器是工作在第三层的网络设备同时兼有交换机的功能可以在不同的链路层接口之间转发数据包因此路由器需要将进来的数据包拆掉网络层和链路层两层首部并重新封装。IP协议不保证传输的可靠性数据包在传输过程中可能丢失可靠性可以在上层协议或应用程序中提供支持。
网络层负责点到点ptoppoint-to-point的传输这里的“点”指主机或路由器而传输层负责端到端etoeend-to-end的传输这里的“端”指源主机和目的主机。传输层可选择TCP或UDP协议。
TCP是一种面向连接的、可靠的协议有点像打电话双方拿起电话互通身份之后就建立了连接然后说话就行了这边说的话那边保证听得到并且是按说话的顺序听到的说完话挂机断开连接。也就是说TCP传输的双方需要首先建立连接之后由TCP协议保证数据收发的可靠性丢失的数据包自动重发上层应用程序收到的总是可靠的数据流通讯之后关闭连接。
UDP是无连接的传输协议不保证可靠性有点像寄信信写好放到邮筒里既不能保证信件在邮递过程中不会丢失也不能保证信件寄送顺序。使用UDP协议的应用程序需要自己完成丢包重发、消息排序等工作。
目的主机收到数据包后如何经过各层协议栈最后到达应用程序呢其过程如下图所示 以太网驱动程序首先根据以太网首部中的“上层协议”字段确定该数据帧的有效载荷payload指除去协议首部之外实际传输的数据是IP、ARP还是RARP协议的数据报然后交给相应的协议处理。假如是IP数据报IP协议再根据IP首部中的“上层协议”字段确定该数据报的有效载荷是TCP、UDP、ICMP还是IGMP然后交给相应的协议处理。假如是TCP段或UDP段TCP或UDP协议再根据TCP首部或UDP首部的“端口号”字段确定应该将应用层数据交给哪个用户进程。IP地址是标识网络中不同主机的地址而端口号就是同一台主机上标识不同进程的地址IP地址和端口号合起来标识网络中唯一的进程。
虽然IP、ARP和RARP数据报都需要以太网驱动程序来封装成帧但是从功能上划分ARP和RARP属于链路层IP属于网络层。虽然ICMP、IGMP、TCP、UDP的数据都需要IP协议来封装成数据报但是从功能上划分ICMP、IGMP与IP同属于网络层TCP和UDP属于传输层。 具体的数据传输过程如下 应用层应用程序生成需要发送的数据。传输层TCP将应用数据进行分段并进行序列化。网络层IP将每个TCP段封装到IP数据包中并添加源IP地址和目标IP地址。数据链路层在发送数据之前网络层的IP数据包会被封装到以太网帧中。以太网帧包含了以太网的目标MAC地址和源MAC地址。物理层以太网帧在物理层被转换为比特流并通过物理介质如以太网电缆发送出去。 协议格式
数据包封装
传输层及其以下的机制由内核提供应用层由用户进程提供后面将介绍如何使用socket API编写应用程序应用程序对通讯数据的含义进行解释而传输层及其以下处理通讯的细节将数据从一台计算机通过一定的路径发送到另一台计算机。应用层数据通过协议栈发到网络上时每层协议都要加上一个数据首部header称为封装Encapsulation如下图所示 TCP/TP数据包封装
不同的协议层对数据包有不同的称谓在传输层叫做段segment在网络层叫做数据报datagram在链路层叫做帧frame。数据封装成帧后发到传输介质上到达目的主机后每层协议再剥掉相应的首部最后将应用层数据交给应用程序处理。
以太网帧格式(链路层)
以太网的帧格式如下所示 这一个图是如何把一个数据封装为实际发送的信息, 无论是TIP/IP发送的IP数据报还是APR请求, 最后都要加上这几个然后进行发送 其中的源地址和目的地址是指网卡的硬件地址也叫MAC地址长度是48位是在网卡出厂时固化的。可在shell中使用ifconfig命令查看“HWaddr 00:15:F2:14:9E:3F”部分就是硬件地址。协议字段有三种值分别对应IP、ARP、RARP。帧尾是CRC校验码。 ARP协议: 通过ip地址获取MAC地址 以太网帧中的数据长度规定最小46字节最大1500字节ARP和RARP数据包的长度不够46字节要在后面补填充位。
最大值1500称为以太网的最大传输单元MTU) 不同的网络类型有不同的MTU如果一个数据包从以太网路由到拨号链路上数据包长度大于拨号链路的MTU则需要对数据包进行分片fragmentation。ifconfig命令输出中也有“MTU:1500”。注意MTU这个概念指数据帧中有效载荷的最大长度不包括帧头长度。 无论是ARP协议还是TCP在TCP/IP协议栈中数据都是通过以太网帧进行传输的。以太网帧是一种在以太网Ethernet上传输数据的标准格式。 ARP数据报格式 ARP协议用于获取目标主机的MAC地址发生在三次握手之前确保在TCP连接建立时源主机已经知道目标主机的MAC地址。之后TCP三次握手建立连接然后才进行数据的传输。ARP和三次握手是在TCP/IP通信过程中的不同阶段但都是确保数据通信的可靠性和正确性的重要步骤。 在网络通讯时源主机的应用程序知道目的主机的IP地址和端口号却不知道目的主机的硬件地址而数据包首先是被网卡接收到再去处理上层协议的如果接收到的数据包的硬件地址与本机不符则直接丢弃。因此在通讯前必须获得目的主机的硬件地址。ARP协议就起到这个作用。源主机发出ARP请求询问“IP地址是192.168.0.1的主机的硬件地址是多少”并将这个请求广播到本地网段以太网帧首部的硬件地址填FF:FF:FF:FF:FF:FF表示广播目的主机接收到广播的ARP请求发现其中的IP地址与本机相符则发送一个ARP应答数据包给源主机将自己的硬件地址填写在应答包中。
每台主机都维护一个ARP缓存表可以用arp -a命令查看。缓存表中的表项有过期时间一般为20分钟如果20分钟内没有再次使用某个表项则该表项失效下次还要发ARP请求来获得目的主机的硬件地址。想一想为什么表项要有过期时间而不是一直有效
ARP数据报的格式如下所示 下面的这一个图里面没有PAD, 上面的这一个少了目的和源地址 ARP数据报格式
源MAC地址、目的MAC地址在以太网首部和ARP请求中各出现一次对于链路层为以太网的情况是多余的但如果链路层是其它类型的网络则有可能是必要的。硬件类型指链路层网络类型1为以太网协议类型指要转换的地址类型0x0800为IP地址后面两个地址长度对于以太网地址和IP地址分别为6和4字节op字段为1表示ARP请求op字段为2表示ARP应答。
看一个具体的例子。 以太网协议 | ARP协议详解-ARP报文结构解析 - 知乎 (zhihu.com) 请求帧如下为了清晰在每行的前面加了字节计数每行16个字节
以太网首部14字节
0000: ff ff ff ff ff ff 00 05 5d 61 58 a8 08 06 ff ff ff ff ff ff : 表示广播 00 05 5d 61 58 a8 : 自己的MAC地址 08 06 : ARP类型 ARP帧28字节
000e: 00 01
0010: 08 00 06 04 00 01 00 05 5d 61 58 a8 c0 a8 00 37
0020: 00 00 00 00 00 00 c0 a8 00 02 00 01: 硬件为以太网 08 00 : 解析一个IP地址 06 :硬件地址长度 04 :协议地址长度, 表示ip地址长度 00 01 : op字段为1表示ARP请求op字段为2表示ARP应答。 00 05 5d 61 58 a8 : 自己的MAC地址 c0 a8 00 37 : IP地址192.168.0.55 00 00 00 00 00 00 : 目的MAC地址, 未知填0 c0 a8 00 02 : 目的地ip地址 填充位18字节
002a: 00 77 31 d2 50 10
0030: fd 78 41 d3 00 00 00 00 00 00 00 00 ARP的填充位用于满足最小帧长度的要求。在以太网帧中最小帧长度为64字节如果ARP请求或应答数据包的长度不足64字节则需要用填充位将其填充到最小帧长度。(其中的数据长度为46字节) 应答的时候 源和目的反向(IP和AMC)把之前的掩码和未知填充位自己的MAC地址 以太网首部目的主机采用广播地址源主机的MAC地址是00:05:5d:61:58:a8上层协议类型0x0806表示ARP。
ARP帧硬件类型0x0001表示以太网协议类型0x0800表示IP协议硬件地址MAC地址长度为6协议地址IP地址长度为4op为0x0001表示请求目的主机的MAC地址源主机MAC地址为00:05:5d:61:58:a8源主机IP地址为c0 a8 00 37192.168.0.55目的主机MAC地址全0待填写目的主机IP地址为c0 a8 00 02192.168.0.2。
由于以太网规定最小数据长度为46字节ARP帧长度只有28字节因此有18字节填充位填充位的内容没有定义与具体实现相关。
应答帧如下
以太网首部
0000: 00 05 5d 61 58 a8 00 05 5d a1 b8 40 08 06 00 05 5d 61 58 a8 : 获取的对方的MAC地址 00 05 5d a1 b8 40 : 自己的MAC地址 08 06 : 模式 ARP帧
0000: 00 01
0010: 08 00 06 04 00 02 00 05 5d a1 b8 40 c0 a8 00 02
0020: 00 05 5d 61 58 a8 c0 a8 00 37 00 01 : 以太网 08 00 : 解析ip 06 04 : 两个长度 00 02 : 应答 00 05 5d a1 b8 40 : 发送端地址(自己的地址) c0 a8 00 02 : 自己的IP地址 00 05 5d 61 58 a8 : 这一个是对方的MAC(请求MAC的那一方) c0 a8 00 37 对方的IP 填充位
0020: 00 77 31 d2 50 10
0030: fd 78 41 d3 00 00 00 00 00 00 00 00
以太网首部目的主机的MAC地址是00:05:5d:61:58:a8源主机的MAC地址是00:05:5d:a1:b8:40上层协议类型0x0806表示ARP。
ARP帧硬件类型0x0001表示以太网协议类型0x0800表示IP协议硬件地址MAC地址长度为6协议地址IP地址长度为4op为0x0002表示应答源主机MAC地址为00:05:5d:a1:b8:40源主机IP地址为c0 a8 00 02192.168.0.2目的主机MAC地址为00:05:5d:61:58:a8目的主机IP地址为c0 a8 00 37192.168.0.55。
IP段格式 IP协议主要用于IP地址的保存 IP数据报格式
IP数据报的首部长度和数据长度都是可变长的但总是4字节的整数倍。对于IPv44位版本字段是4。4位首部长度的数值是以4字节为单位的最小值为5也就是说首部长度最小是4x520字节也就是不带任何选项的IP首部4位能表示的最大值是15也就是说首部长度最大是60字节。8位TOS字段有3个位用来指定IP数据报的优先级目前已经废弃不用还有4个位表示可选的服务类型最小延迟、最大?吐量、最大可靠性、最小成本还有一个位总是0。总长度是整个数据报包括IP首部和IP层payload的字节数。每传一个IP数据报16位的标识加1可用于分片和重新组装数据报。3位标志和13位片偏移用于分片。TTLTime to live)是这样用的源主机为数据包设定一个生存时间比如64每过一个路由器就把该值减1如果减到0就表示路由已经太长了仍然找不到目的主机的网络就丢弃该包因此这个生存时间的单位不是秒而是跳hop。协议字段指示上层协议是TCP、UDP、ICMP还是IGMP。然后是校验和只校验IP首部数据的校验由更高层协议负责。IPv4的IP地址长度为32位。 TCP/IP协议详解 - 知乎 (zhihu.com) IP地址: 标识唯一的一台主机 端口号: 一台主机标识唯一的进程 UDP数据报格式 和TCP协议的主要作用是端口号的选择 UDP数据段
下面分析一帧基于UDP的TFTP协议帧。
以太网首部
0000: 00 05 5d 67 d0 b1 00 05 5d 61 58 a8 08 00
IP首部
0000: 45 00
0010: 00 53 93 25 00 00 80 11 25 ec c0 a8 00 37 c0 a8
0020: 00 01
UDP首部
0020 05 d4 00 45 00 3f ac 40
TFTP协议
0020: 00 01 ‘c’‘:’‘’‘q’
0030: ‘w’‘e’‘r’‘q’‘.’‘q’‘w’e’00 ‘n’‘e’‘t’‘a’‘s’‘c’‘i’
0040: i’00 ‘b’‘l’‘k’‘s’‘i’‘z’e’00 ‘5’‘1’2’00 ‘t’‘i’
0050: ‘m’‘e’‘o’‘u’t’00 ‘1’0’00 ‘t’‘s’‘i’‘z’e’00 ‘0’
0060: 00以太网首部源MAC地址是00:05:5d:61:58:a8目的MAC地址是00:05:5d:67:d0:b1上层协议类型0x0800表示IP。
IP首部每一个字节0x45包含4位版本号和4位首部长度版本号为4即IPv4首部长度为5说明IP首部不带有选项字段。服务类型为0没有使用服务。16位总长度字段包括IP首部和IP层payload的长度为0x0053即83字节加上以太网首部14字节可知整个帧长度是97字节。IP报标识是0x9325标志字段和片偏移字段设置为0x0000就是DF0允许分片MF0此数据报没有更多分片没有分片偏移。TTL是0x80也就是128。上层协议0x11表示UDP协议。IP首部校验和为0x25ec源主机IP是c0 a8 00 37192.168.0.55目的主机IP是c0 a8 00 01192.168.0.1。
UDP首部源端口号0x05d41492是客户端的端口号目的端口号0x004569是TFTP服务的well-known端口号。UDP报长度为0x003f即63字节包括UDP首部和UDP层pay-load的长度。UDP首部和UDP层payload的校验和为0xac40。
TFTP是基于文本的协议各字段之间用字节0分隔开头的00 01表示请求读取一个文件接下来的各字段是
c:\qwerq.qwe
netascii
blksize 512
timeout 10
tsize 0
一般的网络通信都是像TFTP协议这样通信的双方分别是客户端和服务器客户端主动发起请求上面的例子就是客户端发起的请求帧而服务器被动地等待、接收和应答请求。客户端的IP地址和端口号唯一标识了该主机上的TFTP客户端进程服务器的IP地址和端口号唯一标识了该主机上的TFTP服务进程由于客户端是主动发起请求的一方它必须知道服务器的IP地址和TFTP服务进程的端口号所以一些常见的网络协议有默认的服务器端口例如HTTP服务默认TCP协议的80端口FTP服务默认TCP协议的21端口TFTP服务默认UDP协议的69端口如上例所示。在使用客户端程序时必须指定服务器的主机名或IP地址如果不明确指定端口号则采用默认端口请读者查阅ftp、tftp等程序的man page了解如何指定端口号。/etc/services中列出了所有well-known的服务端口和对应的传输层协议这是由IANAInternet Assigned Numbers Authority规定的其中有些服务既可以用TCP也可以用UDP为了清晰IANA规定这样的服务采用相同的TCP或UDP默认端口号而另外一些TCP和UDP的相同端口号却对应不同的服务。
很多服务有well-known的端口号然而客户端程序的端口号却不必是well-known的往往是每次运行客户端程序时由系统自动分配一个空闲的端口号用完就释放掉称为ephemeral的端口号想想这是为什么
前面提过UDP协议不面向连接也不保证传输的可靠性例如
发送端的UDP协议层只管把应用层传来的数据封装成段交给IP协议层就算完成任务了如果因为网络故障该段无法发到对方UDP协议层也不会给应用层返回任何错误信息。
接收端的UDP协议层只管把收到的数据根据端口号交给相应的应用程序就算完成任务了如果发送端发来多个数据包并且在网络上经过不同的路由到达接收端时顺序已经错乱了UDP协议层也不保证按发送时的顺序交给应用层。
通常接收端的UDP协议层将收到的数据放在一个固定大小的缓冲区中等待应用程序来提取和处理如果应用程序提取和处理的速度很慢而发送端发送的速度很快就会丢失数据包UDP协议层并不报告这种错误。
因此使用UDP协议的应用程序必须考虑到这些可能的问题并实现适当的解决方案例如等待应答、超时重发、为数据包编号、流量控制等。一般使用UDP协议的应用程序实现都比较简单只是发送一些对可靠性要求不高的消息而不发送大量的数据。例如基于UDP的TFTP协议一般只用于传送小文件所以才叫trivial的ftp而基于TCP的FTP协议适用于 各种文件的传输。TCP协议又是如何用面向连接的服务来代替应用程序解决传输的可靠性问题呢。
TCP数据报格式 TCP数据段
与UDP协议一样也有源端口号和目的端口号通讯的双方由IP地址和端口号标识。32位序号: 以一个随机数为起始, 每一次加上数据的长度32位确认序号: 发送期望得到的数据的起始位置4位首部长度和IP协议头类似表示TCP协议头的长度以4字节为单位因此TCP协议头最长可以是4x1560字节如果没有选项字段TCP协议头最短20字节。URG、ACK、PSH、RST、SYN、FIN是六个控制位 ACK确认序号有效RST重置连接SYN发起了一个新连接FIN释放一个连接PSH: 当 PSH 1 的时候表示该报文段高优先级 16位窗口: 告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据16位检验和将TCP协议头和数据都计算在内。紧急指针: 仅在 URG 1 时才有意义它指出本报文段中的紧急数据的字节数。各种选项
TCP协议
TCP通信时序
下图是一次TCP通讯的时序图。TCP连接建立断开。包含大家熟知的三次握手和四次挥手。 三次握手 SYN: 请求建立连接 1000(0), 一个随机的额起始位置, 以及数据的大小为0 mss 1460可以接受的信息的大小, 这一个1460是一个以太网帧减去各种头部以后实际可以携带的数据大小 SYN请求建立连接 8000(0)一个随机的起始位置, 数据大小为1 ACK应答标志位 1001表示下一次希望获取的数据 ASK请求8001 在这个例子中首先客户端主动发起连接、发送请求然后服务器端响应请求然后客户端主动关闭连接。两条竖线表示通讯的两端从上到下表示时间的先后顺序注意数据从一端传到网络的另一端也需要时间所以图中的箭头都是斜的。双方发送的段按时间顺序编号为1-10各段中的主要信息在箭头上标出
建立连接三次握手的过程
客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的段1。
客户端发出段1SYN位表示连接请求。序号是1000这个序号在网络通讯中用作临时的地址每发一个数据字节这个序号要加1这样在接收端可以根据序号排出数据包的正确顺序也可以发现丢包的情况另外规定SYN位和FIN位也要占一个序号这次虽然没发数据但是由于发了SYN位因此下次再发送应该用序号1001。mss表示最大段尺寸如果一个段太大封装成帧后超过了链路层的最大帧长度就必须在IP层分片为了避免这种情况客户端声明自己的最大段尺寸建议服务器端发来的段不要超过这个长度。
服务器端回应客户端是三次握手中的第2个报文段同时带ACK标志和SYN标志。它表示对刚才客户端SYN的回应同时又发送SYN给客户端询问客户端是否准备好进行数据通讯。
服务器发出段2也带有SYN位同时置ACK位表示确认确认序号是1001表示“我接收到序号1000及其以前所有的段请你下次发送序号为1001的段”也就是应答了客户端的连接请求同时也给客户端发出一个连接请求同时声明最大尺寸为1024。
客户必须再次回应服务器端一个ACK报文这是报文段3。
客户端发出段3对服务器的连接请求进行应答确认序号是8001。在这个过程中客户端和服务器分别给对方发了连接请求也应答了对方的连接请求其中服务器的请求和应答在一个段中发出因此一共有三个段用于建立连接称为“三方握手three-way-handshake”。在建立连接的同时双方协商了一些信息例如双方发送序号的初始值、最大段尺寸等。这一次是可以带数据的, 但是通常情况不会带 这三次的操作是内核完成的, 实际的用户对用的函数是accept和connect, 这两个成功执行返回 建立三次握手主要是因为A发送了再一次的确认那么A为什么会再确认一次呢主要是为了防止已失效的连接请求报文段又突然传送给B从而产生了错误。 如果采用两次握手会出现以下情况 客户端向服务器端发送的请求报文由于网络等原因滞留未能发送到服务器端此时连接请求报文失效客户端会再次向服务器端发送请求报文之后与服务器端建立连接当连接释放后由于网络通畅了第一次客户端发送的请求报文又突然到达了服务器端这条请求报文本该失效了但此时服务器端误认为客户端又发送了一次连接请求两次握手建立好连接此时客户端忽略服务器端发来的确认也不发送数据造成不必要的错误和网络资源的浪费。 如果采用三次握手的话就算那条失效的报文发送到服务器端服务器端确认并向客户端发送报文但此时客户端不会发出确认由于客户端没有确认由于服务器端没有接收到确认就会知道客户端没有请求连接。 在TCP通讯中如果一方收到另一方发来的段读出其中的目的端口号发现本机并没有任何进程使用这个端口就会应答一个包含RST位的段给另一方。例如服务器并没有任何进程使用8080端口我们却用telnet客户端去连接它服务器收到客户端发来的SYN段就会应答一个RST段客户端的telnet程序收到RST段后报告错误Connection refused $ telnet 192.168.0.200 8080Trying 192.168.0.200...telnet: Unable to connect to remote host: Connection refused数据传输的过程 客户端发出段4包含从序号1001开始的20个字节数据。服务器发出段5确认序号为1021对序号为1001-1020的数据表示确认收到同时请求发送序号1021开始的数据服务器在应答的同时也向客户端发送从序号8001开始的10个字节数据这称为piggyback。客户端发出段6对服务器发来的序号为8001-8010的数据表示确认收到请求发送序号8011开始的数据。
在数据传输过程中ACK和确认序号是非常重要的应用程序交给TCP协议发送的数据会暂存在TCP层的发送缓冲区中发出数据包给对方之后只有收到对方应答的ACK段才知道该数据包确实发到了对方可以从发送缓冲区中释放掉了如果因为网络故障丢失了数据包或者丢失了对方发回的ACK段经过等待超时后TCP协议自动将发送缓冲区中的数据包重发。
滑动窗口 (TCP流量控制) 实际使用的时候不需要对每一次的信息都回应 发送端发起连接声明最大段尺寸是1460初始序号是0窗口大小是4K表示“我的接收缓冲区还有4K字节空闲你发的数据不要超过4K”。 接收端应答连接请求声明最大段尺寸是1024初始序号是8000窗口大小是6K。发送端应答三方握手结束。发送端发出段4-9每个段带1K的数据发送端根据窗口大小知道接收端的缓冲区满了因此停止发送数据。 在回应之前客户端已经发送了很多数据, 回应6145, 表示在这之前的所有数据都收到了, 不需要回应每一次发送 接收端的应用程序提走2K数据接收缓冲区又有了2K空闲接收端发出段10在应答已收到6K数据的同时声明窗口大小为2K。 接收端的应用程序又提走2K数据接收缓冲区有4K空闲接收端发出段11重新声明窗口大小为4K。 发送端发出段12-13每个段带2K数据段13同时还包含FIN位。 接收端应答接收到的2K数据6145-8192再加上FIN位占一个序号8193因此应答序号是8194连接处于半关闭状态接收端同时声明窗口大小为2K。 接收端的应用程序提走2K数据接收端重新声明窗口大小为4K。 接收端的应用程序提走剩下的2K数据接收缓冲区全空接收端重新声明窗口大小为6K。 接收端的应用程序在提走全部数据后决定关闭连接发出段17包含FIN位发送端应答连接完全关闭。 上图在接收端用小方块表示1K数据实心的小方块表示已接收到的数据虚线框表示接收缓冲区因此套在虚线框中的空心小方块表示窗口大小从图中可以看出随着应用程序提走数据虚线框是向右滑动的因此称为滑动窗口。 从这个例子还可以看出发送端是一K一K地发送数据而接收端的应用程序可以两K两K地提走数据当然也有可能一次提走3K或6K数据或者一次只提走几个字节的数据。也就是说应用程序所看到的数据是一个整体或说是一个流stream在底层通讯中这些数据可能被拆成很多数据包来发送但是一个数据包有多少字节对应用程序是不可见的因此TCP协议是面向流的协议。而UDP是面向消息的协议每个UDP段都是一条消息应用程序必须以消息为单位提取数据不能一次提取任意字节的数据这一点和TCP是很不同的。 关闭连接 由于TCP连接是全双工的因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭而另一方执行被动关闭。
客户端发出段7FIN位表示关闭连接的请求。服务器发出段8应答客户端的关闭连接请求。服务器发出段9其中也包含FIN位向客户端发送关闭连接请求。客户端发出段10应答服务器的关闭连接请求。
建立连接的过程是三方握手而关闭连接通常需要4个段服务器的应答和关闭连接请求通常不合并在一个段中因为有连接半关闭的情况这种情况下客户端关闭连接之后就不能再发送数据给服务器了但是服务器还可以发送数据给客户端直到服务器也关闭连接为止。 这一个协议支持半关闭, 这个时候信息的传递是单向的 这两次会关闭发起者的读缓冲区, 以及接受者的写缓冲区, 关闭的不是套接字, 所以还可以发送信息 所以需要关闭两次 半关闭
当TCP链接中A发送FIN请求关闭B端回应ACK后A端进入FIN_WAIT_2状态B没有立即发送FIN给A时A方处在半链接状态此时A可以接收B发送的数据但是A已不能再向B发送数据。
从程序的角度可以使用API来控制实现半连接状态。
#include sys/socket.hint shutdown(int sockfd, int how);sockfd: 需要关闭的socket的描述符 how: 允许为shutdown操作选择以下几种方式: SHUT_RD(0) 关闭sockfd上的读功能此选项将不允许sockfd进行读操作。 该套接字不再接收数据任何当前在套接字接受缓冲区的数据将被无声的丢弃掉。 SHUT_WR(1): 关闭sockfd的写功能此选项将不允许sockfd进行写操作。进程不能在对此套接字发出写操作。 SHUT_RDWR(2): 关闭sockfd的读写功能。相当于调用shutdown两次首先是以SHUT_RD,然后以SHUT_WR。 使用close中止一个连接但它只是减少描述符的引用计数并不直接关闭连接只有当描述符的引用计数为0时才关闭连接。
shutdown 不考虑描述符的引用计数直接关闭描述符。也可选择中止一个方向的连接只中止读或只中止写。
注意:
如果有多个进程共享一个套接字close每被调用一次计数减1直到计数为0时也就是所用进程都调用了close套接字将被释放。在多进程中如果一个进程调用了shutdown(sfd, SHUT_RDWR)后其它的进程将无法进行通信。但如果一个进程close(sfd)将不会影响到其它进程。
TCP状态转换
这个图N多人都知道它排除和定位网络或系统故障时大有帮助但是怎样牢牢地将这张图刻在脑中呢那么你就一定要对这张图的每一个状态及转换的过程有深刻的认识不能只停留在一知半解之中。下面对这张图的11种状态详细解析一下以便加强记忆不过在这之前先回顾一下TCP建立连接的三次握手过程以及 关闭连接的四次握手过程。 TCP状态转换图
**CLOSED**表示初始状态。
**LISTEN**该状态表示服务器端的某个SOCKET处于监听状态可以接受连接。
**SYN_SENT**这个状态与SYN_RCVD遥相呼应当客户端SOCKET执行CONNECT连接时它首先发送SYN报文随即进入到了SYN_SENT状态并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
SYN_RCVD: 该状态表示接收到SYN报文在正常情况下这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态很短暂。此种状态时当收到客户端的ACK报文后会进入到ESTABLISHED状态。
**ESTABLISHED**表示连接已经建立。
FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。区别是
FIN_WAIT_1状态是当socket在ESTABLISHED状态时想主动关闭连接向对方发送了FIN报文此时该socket进入到FIN_WAIT_1状态。
FIN_WAIT_2状态是当对方回应ACK后该socket进入到FIN_WAIT_2状态正常情况下对方应马上回应ACK报文所以FIN_WAIT_1状态一般较难见到而FIN_WAIT_2状态可用netstat看到。
FIN_WAIT_2主动关闭链接的一方发出FIN收到ACK以后进入该状态。称之为半连接或半关闭状态。该状态下的socket只能接收数据不能发。
TIME_WAIT: 表示收到了对方的FIN报文并发送出了ACK报文等2MSL后即可回到CLOSED可用状态。如果FIN_WAIT_1状态下收到对方同时带 FIN标志和ACK标志的报文时可以直接进入到TIME_WAIT状态而无须经过FIN_WAIT_2状态。 发完最后一个ASK以后, 需要等待看对方有没有收到, 没有收到的话, 对方会一直发送FIN信号过来 在这一个等待的时长的时候可以使用setsockopt函数进行端口的复用, 提高用户体验 CLOSING: 这种状态较特殊属于一种较罕见的状态。正常情况下当你发送FIN报文后按理来说是应该先收到或同时收到对方的 ACK报文再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后并没有收到对方的ACK报文反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢如果双方几乎在同时close一个SOCKET的话那么就出现了双方同时发送FIN报文的情况也即会出现CLOSING状态表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 此种状态表示在等待关闭。当对方关闭一个SOCKET后发送FIN报文给自己系统会回应一个ACK报文给对方此时则进入到CLOSE_WAIT状态。接下来呢察看是否还有数据发送给对方如果没有可以 close这个SOCKET发送FIN报文给对方即关闭连接。所以在CLOSE_WAIT状态下需要关闭连接。
LAST_ACK: 该状态是被动关闭一方在发送FIN报文后最后等待对方的ACK报文。当收到ACK报文后即可以进入到CLOSED可用状态。 可以使用命令netstate | grep 端口号查看对应端口的端口号 C/S模型
client-server:客户端-服务器模型
优缺点
可以缓存大量数据, 加载快, 可以自定义协议, 方便迭代
安转的程序不可控, 安全性比较低
B/S模型
browser-server: 浏览器服务器
优缺点
不能缓存大量的数据, 严格遵循http, 可以跨平台, 开发的工作量比较小
