网络详解(get和post请求,http状态码,tcp与udp的区别)

✍转载自:
https://www.cnblogs.com/fundebug/p/differences-of-tcp-and-udp.html
https://zhuanlan.zhihu.com/p/78244069
https://zhuanlan.zhihu.com/p/108822858

》网站请求方式:GET 和POST

GET:

GET通常用于获取服务端数据。

常见发起GET请求的方式有:url 、src/href、表单(form)。

GET方式提交数据的格式,如下:

index.php?userName=jack&password=123

(注意:index.php?key=value&key=value 的形式,其中: userName=jack&password=123 叫做查询字符串)

  • 参数名与参数值之间没有空格

  • 参数值不需要使用单双引号包括

GET方式提交数据特点:

1、get方式在url后面拼接参数,只能以文本的形式传递参数。

2、传递的数据量小,4kb左右(不同浏览器会有差异)。

3、安全性低,会将信息显示在地址栏。

4、速度快,通常用于对安全性要求不高的请求。

POST请求:

POST就是发送、提交。即:可以向指定的资源提交要被处理的数据。

如果使用表单方式进行提交,表单的method必须设置为POST。

post方式提交的特点:

1、post提交数据相对于get的安全性高一些。(注意:抓包软件也会抓到post的内容,安全性要求高可以进行加密)

2、传递数据量大,请求对数据长度没有要求。

3、请求不会被缓存,也不会保留在浏览器的历史记录中。

4、用于密码等安全性要求高的场合,提交数据量较大的场合,如上传文件,发布文章等。

5、POST方式提交数据上限默认为8M(可以在PHP的配置文件post_max_size选项中修改)

》常见HTTP状态码

200 :成功处理了请求,一般情况下都是返回此状态码
201 :请求成功并且服务器创建了新的资源
202 :接受请求但没创建资源
300 :重定向
400 :服务器不理解请求的语法
401 :请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应
403 :服务器拒绝请求
404 :服务器找不到请求的网页
500 :服务器内部错误
502 :错误网关
503 :服务暂不可用
504 :网关超时
505 :HTTP版本不受支持

》TCP 与 UDP

一、TCP/IP网络模型

计算机与网络设备要相互通信,双方就必须基于相同的方法。比如,如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信,所有的这一切都需要一种规则。而我们就把这种规则称为协议(protocol)。

TCP/IP 是互联网相关的各类协议族的总称,比如:TCP,UDP,IP,FTP,HTTP,ICMP,SMTP 等都属于 TCP/IP 族内的协议。

TCP/IP模型是互联网的基础,它是一系列网络协议的总称。这些协议可以划分为四层,分别为链路层、网络层、传输层和应用层。

  • 链路层:负责封装和解封装IP报文,发送和接受ARP/RARP报文等。
  • 网络层:负责路由以及把分组报文发送给目标网络或主机。
  • 传输层:负责对报文进行分组和重组,并以TCP或UDP协议格式封装报文。
  • 应用层:负责向用户提供应用程序,比如HTTP、FTP、Telnet、DNS、SMTP等。
    在这里插入图片描述
    在网络体系结构中网络通信的建立必须是在通信双方的对等层进行,不能交错。 在整个数据传输过程中,数据在发送端时经过各层时都要附加上相应层的协议头和协议尾(仅数据链路层需要封装协议尾)部分,也就是要对数据进行协议封装,以标识对应层所用的通信协议。接下去介绍TCP/IP 中有两个具有代表性的传输层协议----TCPUDP
二、UDP 、TCP 首部格式

UDP:
在这里插入图片描述
源端口: 这个字段占据 UDP 报文头的前 16 位,通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的,所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号,则把这个字段设置为 0。这样,接收端的应用程序就不能发送响应了。

目的端口: 接收端计算机上 UDP 软件使用的端口,占据 16 位。

长度: 该字段占据 16 位,表示 UDP 数据报长度,包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节,所以这个值最小为 8。

校验和: 该字段占据 16 位,可以检验数据在传输过程中是否被损坏。

TCP:(TCP 首部格式比 UDP 复杂)
在这里插入图片描述
序号: 用于对字节流进行编号,例如序号为 301,表示第一个字节的编号为 301,如果携带的数据长度为 100 字节,那么下一个报文段的序号应为 401。

确认号: 期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段,序号为 501,携带的数据长度为 200 字节,因此 B 期望下一个报文段的序号为 701,B 发送给 A 的确认报文段中确认号就为 701。

数据偏移: 指的是数据部分距离报文段起始处的偏移量,实际上指的是首部的长度。

控制位: 八位从左到右分别是 CWR,ECE,URG,ACK,PSH,RST,SYN,FIN。

  • CWR: CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段,ECE 标志为 1 时,则通知对方已将拥塞窗口缩小;

  • ECE: 若其值为 1 则会通知对方,从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1;

  • URG: 该位设为 1,表示包中有需要紧急处理的数据,对于需要紧急处理的数据,与后面的紧急指针有关;

  • ACK: 该位设为 1,确认应答的字段有效,TCP规定除了最初建立连接时的 SYN 包之外该位必须设为 1;

  • PSH: 该位设为 1,表示需要将收到的数据立刻传给上层应用协议,若设为 0,则先将数据进行缓存;

  • RST: 该位设为 1,表示 TCP 连接出现异常必须强制断开连接;

  • SYN: 用于建立连接,该位设为 1,表示希望建立连接,并在其序列号的字段进行序列号初值设定;

  • FIN: 该位设为 1,表示今后不再有数据发送,希望断开连接。当通信结束希望断开连接时,通信双方的主机之间就可以相互交换 FIN 位置为 1 的 TCP 段。

    • 每个主机又对对方的 FIN 包进行确认应答之后可以断开连接。不过,主机收到 FIN 设置为 1 的 TCP 段之后不必马上回复一个 FIN包,而是可以等到缓冲区中的所有数据都因为已成功发送而被自动删除之后再发 FIN 包;

窗口: 窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制,是因为接收方的数据缓存空间是有限的。

校验和: 奇偶校验,此校验和是对整个的 TCP 报文段,包括 TCP 头部和 TCP 数据,以 16 位字进行计算所得。由发送端计算和存储,并由接收端进行验证。

紧急指针: 只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量,和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

选项和填充: 最常见的可选字段是最长报文大小,又称为MSS(Maximum Segment Size),每个连接方通常都在通信的第一个报文段(为建立连接而设置SYN标志为1的那个段)中指明这个选项,它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍,所以要加填充位,即在这个字段中加入额外的零,以保证TCP头是32的整数倍。

数据部分: TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时,双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送,也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中,也会发送不带任何数据的报文段。

三、UDP

UDP协议全称是用户数据报协议,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在第四层——传输层,处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。

【概括为:UDP是无连接的,尽最大可能交付,没有拥塞控制,面向报文(对于应用程序传下来的报文不合并也不拆分,只是添加 UDP 首部),支持一对一、一对多、多对一和多对多的交互通信。】

它有以下几个特点:
1、面向无连接

首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的,想发数据就可以开始发送了。并且也只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。

具体来说就是:

  • 在发送端,应用层将数据传递给传输层的 UDP 协议,UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议,然后就传递给网络层了
  • 在接收端,网络层将数据传递给传输层,UDP 只去除 IP 报文头就传递给应用层,不会任何拼接操作

2、有单播,多播,广播的功能
UDP 不止支持一对一的传输方式,同样支持一对多,多对多,多对一的方式,也就是说 UDP 提供了单播,多播,广播的功能。

3、 UDP是面向报文的
发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。因此,应用程序必须选择合适大小的报文

4、 不可靠性
首先不可靠性体现在无连接上,通信都不需要建立连接,想发就发,这样的情况肯定不可靠。

并且收到什么数据就传递什么数据,并且也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据了。

再者网络环境时好时坏,但是 UDP 因为没有拥塞控制,一直会以恒定的速度发送数据。即使网络条件不好,也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包,但是优点也很明显,在某些实时性要求高的场景(比如电话会议)就需要使用 UDP 而不是 TCP。【UDP只会把想发的数据报文一股脑的丢给对方,并不在意数据有无安全完整到达】

5、头部开销小,传输数据报文时是很高效的
UDP 的头部开销小,只有八字节,相比 TCP 的至少二十字节要少得多,在传输数据报文时是很高效的

四、TCP

当一台计算机想要与另一台计算机通讯时,两台计算机之间的通信需要畅通且可靠,这样才能保证正确收发数据。例如,当你想查看网页或查看电子邮件时,希望完整且按顺序查看网页,而不丢失任何内容。当你下载文件时,希望获得的是完整的文件,而不仅仅是文件的一部分,因为如果数据丢失或乱序,都不是你希望得到的结果,于是就用到了TCP。

TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议,流就是指不间断的数据结构,你可以把它想象成排水管中的水流。由 IETF 的RFC 793定义。

【概括为:是面向连接的,提供可靠交付,有流量控制,拥塞控制,提供全双工通信,面向字节流(把应用层传下来的报文看成字节流,把字节流组织成大小不等的数据块),每一条TCP 连接只能是点对点的(一对一)】

1、TCP协议的特点

  • 面向连接
    面向连接,是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”,这样能建立可靠的连接。建立连接,是为数据的可靠传输打下了基础。

  • 仅支持单播传输
    每条TCP传输连接只能有两个端点,只能进行点对点的数据传输,不支持多播和广播传输方式。

  • 面向字节流
    TCP不像UDP那样一个个报文独立地传输,而是在不保留报文边界的情况下以字节流方式进行传输。

  • 可靠传输
    对于可靠传输,判断丢包,误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据(假设丢失了)将会被重传。

  • 提供拥塞控制
    当网络出现拥塞的时候,TCP能够减小向网络注入数据的速率和数量,缓解拥塞

  • TCP提供全双工通信
    TCP允许通信双方的应用程序在任何时候都能发送数据,因为TCP连接的两端都设有缓存,用来临时存放双向通信的数据。当然,TCP可以立即发送一个数据段,也可以缓存一段时间以便一次发送更多的数据段(最大的数据段大小取决于MSS)

2、TCP连接过程(三次握手)
如下图所示,可以看到建立一个TCP连接的过程为(三次握手的过程):
在这里插入图片描述
为什么是三次握手?

(一)确认通信能力
我们要明白,如果需要进行通信,首先需要保证的是双方都具有发信和收信能力。在不知双方能力状态下进行的通信都是无法保证可靠性和通信效率的。那么通信双方如何确认对方的通信能力呢?

  • 1、A请求B进行连接。(B已确认B的收信能力和A的发信能力)
  • 2、B返回ACK相应。(A已确认双方的收发能力)
  • 3、A返回ACK并建立连接。(B确认双方收发能力) 上面可以看到,至少是进行三次握手,才能确认双方能力。

(二)防止产生脏数据连接
网络通信情况复杂,不可能保证每一消息都能正常到达其目的地。在TCP连接中,TTL的网络报文的生存时间一般都会比TCP的连接超时时间要长。这样就有可能出现一个问题。A在发送第一次连接请求时,可能网络拥塞,导致数据包未短时间内到达。到达超时时间后,A又发送了一次连接请求,这次正常进行连接。连接结束断开后,A的第一次连接请求到达B,B返回ack。如果是两次握手,A通过当前的状态,直接拒绝B的请求,但B会单方面认为连接已经建立,实际上并不是…

第一次握手

  • 首先会将TCP的header部分的控制位中的SYN置为1。表示希望建立连接。
  • 还有一个重要的数据,seq,即序号。这个东西是干嘛用的呢?这个涉及到TCP安全性和可靠性,与ack即确认号紧密相关。TCP在传输数据时,如果数据比较大,会进行拆分操作,将大数据拆成一个个小的数据包。序号就是在这个时候用的。我们必须要知道这个包的顺序是什么,才能把真正的数据在服务端还原。seq的顺序并不是从0或者1开始的,而是一个随机值。因为如果序号从1开始,那么整个通信的过程非常容易被预测。正因为是随机的,所以对方不知道你的seq,所以我们需要在开始收发数据之前,将seq先发送给对方。序号的初始值的传递就是通过SYN=1的操作传递的。

客户端此时处于同步状态,即可以建立连接。服务端处于监听状态。

第二次握手

  • 标志位。因为已经收到了客户端的建立连接请求。所以必须要发送ack,以告知客户端自己已经收到消息。所以ACK的标志位要置为1,且SYN也是1,因为还未建立连接。
  • seq。同第一次握手一样,也是一个随机值(TCP为全双工,所以双方都需要保留seq方便处理数据包)。
  • ack。是对客户端发过来的序列号进行计算得到的

服务端处于SYN接收状态。

第三次握手

  • 标志位。此时只需要ACK=1。SYN已经不需要了,双方已经同步完seq等信息。
  • seq。可以说是第二次握手收到的ack。
  • ack。是对第二次握手收到的序列号进行计算得到的。用以告知已收到二次握手信息。

客户端处于连接建立状态,服务端收到信息之后也会进入连接建立状态,双方可以进行通信。

3、TCP断开链接(四次挥手)
TCP连接在数据传输完成之后需要关闭,不然会一直占用系统资源。TCP的连接关闭需要四次通信才行。
在这里插入图片描述
为什么是四次挥手?

拿A、B来举例。假设A要主动断开和B的连接。

  • 1、A发送断开请求。(需要等待B的回复,不然B未收到消息 就单方面的断开有点不负责任。超时重传)
  • 2、B收到请求并回复A。(B收到请求后,很伤心,但是没有办法,只能断开连接,但是B是被动的接收断开,所以需要通知其应用程序做关闭准备)
  • 3、B这边准备完了,通知A可以断开了。
  • 4、A回复B,我收到消息了,断开连接吧。

关闭由哪方开始?
答案是哪边都可以,无论是客户端还是服务器端,都可以主动发起关闭请求。发起关闭请求的前提是数据发送完毕,不一定非得等待对方确认完成。

第一次挥手
假设客户端发起关闭请求。那么客户端发完消息后,会进入FIN_WAIT阶段。此处已经无法再发送应用程序消息,只能处理关闭相关信息。

第二次挥手
服务端收到第一次挥手消息后,返回收到消息的ack。服务端会进入CLOSE_WAIT阶段。这个阶段是等待关闭阶段,通知应用程序发送剩余数据,处理现场信息,关闭相应资源

第三次挥手
你应该有点好奇为什么第三次挥手和第二次挥手都是同一个服务。第二次主要是一个ack响应,第三次主要是一个服务端关闭通知消息。两者目的不同。等到三次挥手完毕,那么服务端会进入LAST_ACK状态,即等待最后客户端(主动发起关闭的一方)的ack确认。

第四次挥手
第四次挥手是主动发起关闭的一方A,对被动关闭一方B的FIN消息的确认。第四次信息发送完成后,A会进入TIME_WAIT阶段,而不是直接删除套接字。具体原因我们在下面讲。而收到第四次挥手信息后,B会直接进行关闭操作。

为什么会有TIME_WAIT?
还是那句话,网络并不是一个理想世界,任何异常情况都有可能发生。为了保证TCP连接能够正常关闭,主动发起关闭方不能直接删除套接字,而是需要经过一段时间等待。这个时间一般是2MSL(Maxumun Segment Lifetime 最大报文生存时间)。原因如下:

  • 确认被动关闭方能够正常进入关闭状态。假设B未收到A最后的一个ack,会再次发送FIN消息(第三次挥手),如果A已经CLOSE了,那么B就会一直重试发送。所以A必须要进行一段时间的等待。
  • 防止失效请求。假设A关闭了此次连接,又重新在原来的端口号上开启了新的连接。原来在网络上发送的一些包(已失效但未超过ttl)到来之后,无法进行区分是否是正常的包,导致数据混乱。

举个例子来证明没有TIME_WAIT的情况。

  • 1、A断开了,并且删除了套接字。
  • 2、B没有收到A的最后一次ack,导致FIN重发。
  • 3、A重新开启了新的套接字新的连接,但是这个套接字和之前删除的套接字拥有相同的端口号。
  • 4、B后来重发的FIN会错误的跑到新的套接字,导致A开始执行断开操作。

所以TIME_WAIT也是为了防止上面的误删除。

五、TCP和UDP的比较

1. 对比

UDPTCP
是否连接无连接面向连接
是否可靠不可靠传输,不使用流量控制和拥塞控制可靠传输,可以使用流量控制和拥塞控制
连接对象支持一对一,一对多,多对一和多对多交互通信只能是一对一通信
传输方式面向报文面向字节流
首部开销首部开销小,仅8字节首部最小20字节,最大60字节
适用场景适用于实时应用(IP电话、视频会议、直播等)适用于要求可靠传输的应用,例如文件传输

2. 总结

  • TCP向上层提供面向连接的可靠服务 ,UDP向上层提供无连接不可靠服务。
  • 虽然 UDP 并没有 TCP 传输来的准确,但是也能在很多实时性要求高的地方有所作为
  • 对数据准确性要求高,速度可以相对较慢的,可以选用TCP
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值