网络基础知识小结

一、Tcp/ip五层网络协议

互联网协议按照功能不同 分为OSI七层模型 或者Tcp/Ip 五层模型 或者 Tcp/ip四层模型

七层网络模型

每层运行常见的物理设备:


网络模型对应的物理设备

我们将应用层、表示层、会话层并做引用层,从Tcp/ip五层模型上来理解每层的由来和作用。

1.1、物理层。

物理层利用电器特性发送高低电平(0、1序列)

  • 物理层由来:上面提到,孤立的计算机之间要想一起玩,就必须接入internet,言外之意就是计算机之间必须完成组网


    image
  • 物理层功能:主要是基于电器特性发送高低电压(电信号),高电压对应数字1,低电压对应数字0

1.2、数据链路层

数据链路层为01序列提供了分组的概念。将数据包分为数据头head和数据data两部分,规定将发送者的mac地址和接收者的mac地址写入数据头中。即以太网协议。

数据链路层,在同一个局域网内,不同主机之间是靠广播进行通信的。

ethernet规定:
一组电信号构成一个数据包,叫做‘帧’
每一数据帧分成:包头head和数据data两部分。

head data
image

head包含:(固定18个字节)
发送者/源地址,6个字节
接收者/目标地址,6个字节
数据类型,6个字节

data包含:(最短46字节,最长1500字节)
数据包的具体内容

head长度+data长度=最短64字节,最长1518字节,超过最大限制就分片发送

mac地址:

head中包含的源和目标地址由来:ethernet规定接入internet的设备都必须具备网卡,发送端和接收端的地址便是指网卡的地址,即mac地址

mac地址:每块网卡出厂时都被烧制上一个世界唯一的mac地址,长度为48位2进制,通常由12位16进制数表示(前六位是厂商编号,后六位是流水线号)

广播:

有了mac地址,同一网络内的两台主机就可以通信了(一台主机通过arp协议获取另外一台主机的mac地址
ethernet采用最原始的方式,广播的方式进行通信,即计算机通信基本靠吼

1.3、网络层(IP层)

网络层(IP层) 为每台主机赋予了一个虚拟的IP地址,通过这个虚拟的IP地址,可以判断两个主机是否处于同一个广播域:

  • 同一广播域的主机间采用广播的方式通信;
  • 不同广播域的主机之间采用用路由的方式分发数据包。

网络层由来:有了ethernet、mac地址、广播的发送方式,世界上的计算机就可以互相通信了。
但世界范围的互联网是有一个个彼此隔离的小的局域网组成的,如果所有的通信都采用以太网的广播方式,那么一台机器发送的包全世界都会收到,不仅仅是效率低的问题了,这会是一种灾难。

ip地址分成两部分:网络部分:标识子网;主机部分:标识主机。
ip地址通过与子网掩码做and,来得出子网标识。

ip数据包

ip数据包也分为head和data部分,无须为ip包定义单独的栏位,直接放入以太网包的data部分

head:长度为20到60字节
data:最长为65,515字节。
而以太网数据包的”数据”部分,最长只有1500字节。因此,如果IP数据包超过了1500字节,它就需要分割成几个以太网数据包,分开发送了

以太网头 ip 头 ip数据

1.4、传输层(Tcp层)

传输层 提出了端口的概念,来区分不同的应用程序。

传输层的由来:

网络层的ip帮我们区分子网,以太网层的mac帮我们找到主机,同一个主机上有多个应用程序。我们通过ip和mac找到了一台特定的主机,如何标识这台主机上的应用程序,答案就是端口。

传输层功能:建立端口到端口的通信

补充:端口范围0-65535,0-1023为系统占用端口

传输层 分为Tcp协议和Udp协议

tcp

以太网头 ip 头 tcp头 数据

udp

以太网头 ip 头 udp头 数据

Tcp头占20个字节,主要信息为源端口号,目的端口号,序列号(seq)、和确认号(ack)

tcp头

Tcp建立连接需要三次握手、Tcp断开连接需要4次挥手。

1.5、应用层(如http)

应用层由来:

用户使用的都是应用程序,均工作与应用层。每个应用程序都会占用一个端口,如http程序占用80端口,https程序占用443端口。

应用层功能:规定应用程序的数据格式。

TCP协议可以为各种各样的程序传递数据,比如Email、WWW、FTP等等。那么,必须有不同协议规定电子邮件、网页、FTP数据的格式,这些应用程序协议就构成了”应用层”。


网络协议示例

参考文章

二、 Tcp三次握手、四次挥手。

Tcp是面向连接的,安全的传输。

Tcp建立连接需要三次握手,Tcp断开连接需要四次挥手。

2.1、Tcp协议头介绍

tcp协议头
  • 序列号(seq)::占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;列号seq就是这个报文段中的第一个字节的数据编号。
  • 确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。
  • 确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
  • 同步SYN,连接建立时用于同步序号。

当SYN=1,ACK=0时表示:这是一个连接请求报文段。同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。

  • 终止FIN:用来释放一个连接。

FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接。

2.2、Tcp建立连接 三次握手

三次握手
  • 第一次握手:建立连接时,客户端发送syn包到服务器,并进入SYN_SENT状态,等待服务器确认;
  • 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
  • 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

2.3、Tcp断开连接 需要四次挥手

四次挥手

当被动方收到主动方的FIN报文通知时,它仅仅表示主动方没有数据再发送给被动方了。但未必被动方所有的数据都完整的发送给了主动方,所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后,再发送FIN报文给主动方,告诉主动方同意关闭连接,所以这里的ACK报文和FIN报文多数情况下都是分开发送的。

  • (1)第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
  • (2)第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。(此时Server端可能还有数据没有完全发送给客户端)
  • (3) Server端完成对Client端的所有数据发送之后,会第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
  • (4)第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server。注意此时Client端的TCP连接还没有释放,必须经过2*MSL(最长报文段寿命)的时间后,没有收到新的服务端消息,才会结束Tcp连接。
  • 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。可以看到,服务器结束TCP连接的时间要比客户端早一些。

2.4、思考题(答案见参考文章2)

  • 为什么连接的时候是三次握手,关闭的时候却是四次握手?
  • 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
  • 为什么不能用两次握手进行连接?

3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。

  • 如果已经建立了连接,但是客户端突然出现故障了怎么办?

TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。
服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

参考文章1

参考文章2

三、SSL/TLS https四次握手过程

http默认端口号是80,
https默认端口号是443

3.1、Https与Http的区别:

HTTP协议运行在TCP之上,所有传输的内容都是明文。

HTTPS运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的。

https与http的区别

3.2、SSL与TLS

SSL :Secure Socketes Layer 安全套接字协议
TLS:Transport Layer Security 传输层安全,TLS是SSL的替代和升级。

TLS与SSL在传输层与应用层之间对网络连接进行加密。是为网络通信提供安全及数据完整性的一种安全协议。

3.3、SSL/TLS加密过程

ssl握手加密过程

1、client客户端向服务端发送https请求

客户端(通常是浏览器)先向服务器发出加密通信的请求,这一步骤会携带一些信息

  • 支持的协议版本,比如TLS 1.0版
  • 一个客户端生成的随机数RandomC,稍后用于生成“协商密钥”。
  • 支持的加密方法,比如RSA公钥加密。
  • 支持的压缩方法。

2、服务器响应

服务器收到客户端请求后,向客户端发出回应,服务器的回应一般包含以下内容

  • 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
  • 一个服务器生成的随机数RandomS,稍后用于生成“协商密钥”*。
  • 客户端支持的加密方法中选择一个作为确认要使用的加密方法,比如RSA公钥加密。
  • 服务器证书。 这个服务器证书就是表明服务器身份的东西,其中也包含了非对称加密中需要使用的公钥。

3、客户端证书校验、生成密码、公钥加密

客户端收到服务器回应以后,首先验证服务器返回的证书。如果证书没有问题,客户端就会从证书中取出服务器的公钥。随机生成一个Pre-Mastater Key,用服务器的公钥加密对Pre-Mastater Key进行加密,发送给服务端。

3、客户端生成协商秘钥

  • 客户端此时持有三个随机数:RandomC、RandomS和Pre-master,利用上面的三个随机数,通过事先商定的加密方法,生成本次会话所用的“协商密钥”。
  • 客户端向服务端发送"编码改变通知",表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项通常也是前面发送的所有内容的hash值,用来供服务器校验。

4、服务端私钥解密、解密握手消息、验证Hash

服务器收到客户端公钥加密的第三个随机数Pre-master key之后,通过自身私钥解密该数值并由之前的RandomC和RandomS计算生成本次会话所用的“会话密钥”。然后,通过约定的Hash算法验证客户端发送的数据完整性。

5、服务端发送加密信息S-C

主要是指

  • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发生的所有内容的hash值,用来供客户端校验.

6、客户端 解密握手消息、验证Hash

客户端解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束。

7、正常加密通信

握手成功之后,所有的通信数据将由之前协商密钥及约定好的算法进行加密解密。

TLS 握手过程

四、http1.0和http2.0的区别

http的主要版本包括:http1.0、http1.1、http2.0

http版本

4.1、http1.1与http1.0的区别

  • 长连接(Persistent Connection)
    HTTP1.1支持长连接和请求的流水线处理,在一个TCP连接上可以串行地传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。

在HTTP1.1中默认开启长连接keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。

  • 节约带宽:Http1.1 header中支持了range参数,允许仅返回一部分请求的数据。支持断点续传功能

HTTP1.0中存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能。HTTP1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,客户端接收到100才开始把请求body发送到服务器;如果返回401,客户端就可以不用发送请求body了节约了带宽。

  • HOST域:Http1.1 支持在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname),HTTP1.0没有host域。随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域,且请求消息中如果没有host域会报告一个错误(400 Bad Request)。

4.2、Http2.0与http1.1的区别

  • 多路复用

HTTP2.0使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级

多路复用
  • 服务器推送
    服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源:HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始,然后在它解析和评估页面的时候,增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求,网络经常是空闲的和未充分使用的。

为了改善延迟,HTTP2.0引入了server push,它允许服务端推送资源给浏览器,在浏览器明确地请求之前,免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源,不用再通过网络。

image
  • 头部数据压缩

在HTTP1.1中,HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言,消息主体都会经过gzip压缩,或者本身传输的就是压缩过后的二进制文件,但状态行和头部却没有经过任何压缩,直接以纯文本传输。

HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快。

参考文章

http1.0、1.1、1.2区别

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,294评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,780评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,001评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,593评论 1 289
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,687评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,679评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,667评论 3 415
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,426评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,872评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,180评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,346评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,019评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,658评论 3 323
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,268评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,495评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,275评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,207评论 2 352

推荐阅读更多精彩内容