网络基础

举报
SHQ5785 发表于 2023/12/14 09:02:12 2023/12/14
【摘要】 一、http 和 https 的区别http是http协议运行在tcp之上,所传输的内容都是明文,客户端和服务器端都无法验证对方的身份。https是http协议运行在SSL/TLS之上,SSL/TLS运行在tcp之上。所有传输的内容都经过加密。加密采用对称加密,但对称加密的秘钥用服务器方的证书进行非对称加密,此外客户端可以验证服务器端的身份,如果配置了客户端验证,服务器方也可以验证客户端的...

一、http 和 https 的区别

  • httphttp协议运行在tcp之上,所传输的内容都是明文,客户端和服务器端都无法验证对方的身份。
  • httpshttp协议运行在SSL/TLS之上,SSL/TLS运行在tcp之上。所有传输的内容都经过加密。加密采用对称加密,但对称加密的秘钥用服务器方的证书进行非对称加密,此外客户端可以验证服务器端的身份,如果配置了客户端验证,服务器方也可以验证客户端的身份。
  • https协议需要到CA申请证书,一般免费证书很少,需要缴费;
  • http是超文本传输协议,信息是明文传输,https则是具有安全性的SSL加密传输协议;
  • httphttps使用的是完全不同的链接方式,所用的端口也不一样,前者是80,后者是443;
  • http的链接很简单,是无状态的。

二、从输入网址到获得网页的过程

  1. 查询DNS,获取域名对应的ip地址;
  2. 浏览器搜索自身的DNS缓存;
  3. 搜索操作系统的DNS缓存;
  4. 读取本地的HOST文件;
  5. 发起一个DNS系统调用;
  6. 宽带运营服务器查看本身缓存;
  7. 运营商服务器发起一个迭代DNS解析请求;
  8. 浏览器获得域名对应的ip地址后,发起HTTP三次握手
  9. TCP/IP链接建立起来后,浏览器就可以向服务器发送HTTP请求;
  10. 服务器接收到这个请求,根据路径参数,经过后端的一些处理生成html页面代码返回给浏览器;
  11. 浏览器拿到完整的html页面代码开始解析和渲染,如果遇到引用外部的js,css,图片等静态资源,它们同样也是一个个的http请求,都需要经过上面的步骤。

三、TCP如何保证可靠传输?三次握手过程?四次挥手过程?

3.1 TCP如何保证可靠传输

  • 数据报校验;
  • 超时重传机制;
  • 应答机制;
  • 对失序数据包重排序;
  • TCP还能提供流量控制;

TCP是什么:
是一种面向连接、可靠、基于字节流的传输层通信协议。

TCP的组成部分:
特别要注意的信息:

  • ACK:TCP协议规定,只有ACK=1时有效,也就是连接建立后所有发送的报文ACK必须为1;
  • SYN:在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文。若对方同意建立连接,则响应的报文中使SYN=1和ACK=1.(SYN置1表示这是一个连接请求或连接接受报文)
  • FIN(finish):表示终结的意思,用来释放一个连接。当FIN=1时,表明此报文段的发送数据已经发送完毕,并要求释放连接。
    这里写图片描述
  • 序号:占4字节,范围(0,232-1),共232个序号。序号增加到232-1后,下一个序号就又回到0(采用取模运算)。TCP是面向字节流的,传输的字节流每一个字节都按照顺序编号,且必须在连接建立时设置,首部中的序号字段指本报文段所发送的数据第一个字节的序号。

例如:一报文段的序号字段值是301,而携带的数据共有100字节,表明第一个字节序号是301,最后一个字节序号是400.下一个报文段的数据序号从401开始,这个301、401叫做报文段序号。

3.2 三次握手的过程

这里写图片描述

  • 第一次握手:首先由Client发出请求连接即SYN=1,ACK=0(TCP规定SYN=1时不能携带数据,但要消耗一个序列号),因此声明自己的序号是seq=x;
  • 第二次握手:然后Server一直监听客户端是否发来请求,监听到客户端有请求发送,核对后进行回复确认,即SYN=1,ACK=1,seq=y, ack=x+1;
  • 第三次握手:然后Client再依次进行确认,但不用SYN,这时即为ACK=1,seq=x+1, ack=y+1. 然后就建立连接;
    问题:为什么进行三次握手,两次确认,两次握手,一次确认不行么?
    问题的根源在于防止已失效的链接请求报文段又传送到server,产生错误

四、什么是“已失效的链接请求报文段”

考虑一种正常的情况:A发出链接请求,但因链接请求报文丢失而未收到确认(可能网络阻塞、断网、断电等)。于是A再重传一次链接请求,后来收到确认(网络环境变好了),建立了链接。数据传输完毕后,就释放了链接。A共发送两个链接请求报文段,其中第一个丢失,第二个到达了B。没有“已失效的链接请求。

现假定一种异常情况,A发送的第一个链接请求报文段并没有丢失,而在某些网络结点长时间滞留,以致延误到链接释放以后的某个时间才到达B。本来这是一个早已失效的报文段,但B收到此失效的链接请求报文段后,就误认为是A又发出一次新的链接请求。于是向A发出确认报文段,同意建立连接。假设不采用三次握手,那么只要B发出确认,新的链接就建立。

由于现在A并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B发送数据。但B却以为新的运输链接已经建立了,并一直等待A发来数据。从而造成B的许多资源白白浪费。

采用三次握手的办法就可以防止上述现象的发生。例如在刚才的情况下,A不会向B的确认发出确认,B由于收不到确认,就知道A并没有要求建立连接。

释放连接的过程:
这里写图片描述
要理解四次挥手的过程,客户端A没有东西发送时,就会请求释放连接,发送一个FIN包(没有数据),此时客户端状态变成FIN_WAIT_1(A不能发数据,但可以接受数据),服务端B接受到A那边的链接已经关闭。B会发送一个确认的包ACK,A收到B的确认后进入FIN_WAIT_2等待状态,等待B释放连接,此时B把要发的数据发给A,发完并向A请求释放连接FIN=1,A收到后回复一个确认消息ACK=1,并进入Time_wait状态,等待2msl.

为什么等待?
假设A回复的确认信息一发送,就断开连接,而这个确认信息在发送的过程中丢失,B在规定时间内没有收到确认,就会重传。若A有time_wait,就会再次确认信息发送。不然会出现异常关闭。

另外B存在一个保活状态,即使A突然故障死机,那B那边的链接资源什么时候释放呢?就是保活时间到了后,B会发送探测信息,以决定是否释放连接。

五、Get和Post的区别

  • 浏览器对url的长度有限制,所以get请求不能代替post请求发送大量数据(get传送数据少,post的传输数据大);
  • get请求不安全(传输过程中是明文的)(post是安全的);
  • get请求是幂等的(多个请求返回同一个结果)(感觉像缓存似的);
  • post请求不能被缓存;

在以下情况中,请使用post请求:

  • 无法使用缓存文件(更新服务器上的文件或数据库);
  • 向服务器发送大量数据(post没有数据量限制);
  • 发送包含未知字符的用户输入时,post比get更稳定也更可靠;

六、 TCP和UDP区别?如何改进TCP

  • UDP是无连接,即发送数据之前不需要建立连接;
  • UDP使用尽最大努力交付,即不保证可靠交付,同时也不能使用拥塞控制;
  • UDP是面向报文,UDP没有拥塞控制,很适合多媒体通信要求;
  • UDP支持一对一,一对多,多对一和多对多的交互通信;
  • UDP的首部开销小,只有8个字节;
  • TCP是面向连接的运输层协议;
  • 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点(一对一);
  • TCP提供可靠交付的服务;
  • TCP提供全双工通道 (html5 websocket就是采用全双工通道);
  • TCP是面向字节流的;
  • 首部最低20个字节;

6.1 TCP加快传输效率的方法

采取一致确认的机制。

【版权声明】本文为华为云社区用户原创内容,未经允许不得转载,如需转载请自行联系原作者进行授权。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。