[网络]应用层协议:HTTP / HTTPS[转载]
Posted 千千寰宇
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[网络]应用层协议:HTTP / HTTPS[转载]相关的知识,希望对你有一定的参考价值。
1 HTTP / HTTPS 概述
1.1 什么是HTTP协议?
摘自百度百科:
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。
所有的WWW文件都必须遵守这个标准。
目的
是保证浏览器与服务器之间的通信、为了提供一种发布和接收HTML页面的方法。
HTTP的工作方式
是客户端与服务器之间的请求-应答协议。
HTTP
协议 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范- HTTP属于OSI网络七层协议模型中的"最上层":应用层协议。由请求和响应构成,是一个标准的客户端服务器模型。HTTP是一个无状态的协议 ( HTTP无状态协议,是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快 ) 。
- HTTP默认端口号为80。它也可以承载在TLS和SSL之上,通过加密、认证的方式实现数据传输的安全,称为HTTPS,HTTPS默认端口号为443。
- 早期HTTP用于传输网页HTML文件,发展到现在,应用变得广泛,客户端软件(PC,Android,iOS等)大部分通过HTTP传输数据。
1.2 从浏览器输入地址URL到呈现页面中间发生了什么事情(通信过程)?
1.2.1 简述
- 浏览器(客户端)进行地址解析。
- 将解析出的域名进行dns解析。
- 通过ip寻址和arp,找到目标(服务器)地址。
- 进行tcp三次握手,建立tcp连接。
- 浏览器发送数据,等待服务器响应。
- 服务器处理请求,并对请求做出响应。
- 浏览器收到服务器响应,得到html代码。
- 渲染页面。
通过以上这些步骤,就完成了
一次完整的http请求
Step1 浏览器(客户端)进行了地址解析
当我们在浏览器中输入一个地址,按下回车后,浏览器获取到的是一个字符串。浏览器此时要对这个地址进行解析,获取协议,主机,端口,路径等信息。
URL的一般格式为(手记会自动过滤尖括号,所以只能上传图片了):
例如:
http://www.imooc.com/article/draft/id/430
这个网址缺少了一些东西,端口号,用户名,密码,query和flag都没有。
这些东西都是非必须的,甚至协议、路径都可以不要,最简洁的方式为imooc.com,浏览器会对一些默认的东西进行补齐。
例如:互联网url默认端口号为80,浏览器默认补齐功能会补齐协议http,有些还会直接在域名前面补上www。
所以,实际上,即使我们输入的是imooc.com,然而实际访问的却是http://www.imooc.com。
Step2 将解析出的域名进行dns解析
第一步地址解析中我们已经获取到服务器的域名。此时就需要将域名换成对应的ip地址,这就是dns解析。dns解析分为以下几个步骤:
- 先查看浏览器dns缓存中是否有域名对应的ip。
- 如果没有,则查看操作系统dns缓存中是否有对应的ip(例如windows的hosts文件)。
- 依旧没有就对本地区的dns服务器发起请求,
- 如果还是没有,就直接到Root Server域名服务器请求解析。
- 这里面有几点需要关注:
- <1>、DNS在进行区域传输的时候使用TCP协议,其它时候则使用UDP协议;
- <2>、全球只有十三台逻辑根服务器,为什么是十三台,请参考https://www.zhihu.com/question/22587247?answer_deleted_redirect=true。其中任何一次解析成功就返回对应的ip地址。
Step3 通过ip寻址和arp,找到目标(服务器)地址
第二步获取到了ip,此时直接通过ip寻址找到ip对应的服务器,然后通过arp协议找到服务器的mac地址。
这里有几点需要注意:
ip地址
(ipv4, 32位)。ip地址是IP协议提供的一种统一的地址格式,它为互联网上的每一个网络和每一台主机分配一个逻辑地址,以此来屏蔽物理地址的差异。ip地址分为A、B、C、D、E五大类:
- A类地址:一个字节(8位)的网络地址和三个字节的主机地址。地址范围为:1.0.0.0~126.255.255.255。
- B类地址:二个字节的网络地址和二个字节的主机地址。地址范围为:128.0.0.0~191.255.255.255。
- C类地址:三个字节的网络地址和一个字节的主机地址。地址范围为:192.0.0.0~223.255.255.255。
- D类地址:D类地址用于多点广播(Multicast),D类IP地址第一个字节以“lll0”开始,它是一个专门保留的地址。地址范围为:224.0.0.0~239.255.255.255。
- E类地址:E类IP地址 以“llll0”开始,为将来使用保留。地址范围为:240.0.0.0~255.255.255.254。,255.255.255.255用于广播地址。
其中缺失了两部分,一个是0开头的,“0”表示该地址是本地主机,不能传送。一个是127开头的,127开头的是网卡自身,常用于测试。这里为什么是十进制的数字,为什么中间有‘.’,其实这都是为了方便人类而人为加上去的。转化为计算机语言就是二进制的,每一个字节八位,八位二进制能表示的最大数字就是255,这样ip地址就齐全了。可能有些人还发现ip地址为 10.170.8.61/23 ,这里涉及到局域网、保留地址和子网掩码。这里的意思是,前23位表示为该台主机的网络地址,该网络有 2^(32-23) = 512台主机。具体就不展开讲了,涉及的内容太深,太多。感兴趣的可以参考https://www.zhihu.com/question/56895036
- IP寻址如何工作?
ip寻址主要有两种方式,一种是同一网段,一种是不同网段。要判断两个IP地址是不是在同一个网段,就将它们的IP地址分别与子网掩码做与运算,得到的结果一网络号,如果网络号相同,就在同一子网,否则,不在同一子网。
同一网段的情况:
主机A和主机B,首先主机A通过本机的hosts表或者wins系统或dns系统先将主机B的计算机名 转换为Ip地址,然后用自己的 Ip地址与子网掩码计算出自己所出的网段,比较目的主机B的ip地址与自己的子网掩码,发现与自己是出于相同的网段,于是在自己的ARP缓存中查找是否有主机B 的mac地址,如果能找到就直接做数据链路层封装并且通过网卡将封装好的以太网帧发送有物理线路上去:如果arp缓存中没有主机B的的mac地址,主机A将启动arp协议通过在本地网络上的arp广播来查询主机B的mac地址,获得主机B的mac地址厚写入arp缓存表,进行数据链路层的封装,发送数据。
不同网段的情况:
不同的数据链路层网络必须分配不同网段的Ip地址并且由路由器将其连接起来。和上面一样,主机A发现和主机B不在同一个网段,于是主机A将知道应该将次数据包发送给自己的缺省网关,即路由器的本地接口。主机A在自己的ARP缓存中查找是否有缺省网关的MAC地址,如果能够找到就直接做数据链路层封装并通过网卡 将封装好的以太网数据帧发送到物理线路上去,如果arp缓存表中没有缺省网关的Mac地址,主机A将启动arp协议通过在本地网络上的arp广播来查询缺省网关的mac地址,获得缺省网关的mac地址后写入arp缓存表,进行数据链路层的封装,发送数据。数据帧到达路由器的接受接口后首先解封装,变成ip数据包,对ip 包进行处理,根据目的Ip地址查找路由表,决定转发接口后做适应转发接口数据链路层协议帧的封装,并且发送到下一跳路由器,次过程继续直至到达目的的网络与目的主机。整个过程有点像dns解析,只是dns服务器换成了下一跳路由器,udp编程了tcp,其他差别不大。
- arp。arp就是地址转化协议,也就是把ip地址转化为mac地址。和dns很像,先查缓存,然后查路由器。
- mac地址。mac地址就是计算机的物理地址,每个网卡出厂时,被生产厂家烧制在网卡上。采用十六进制数表示,共六个字节(48位)。三个字节是由IEEE的注册管理机构RA负责给不同厂家分配的代码(高位24位),也称为“编制上唯一的标识符”(Organizationally Unique Identifier),后三个字节(低位24位)由各厂家自行指派给生产的适配器接口,称为扩展标识符(唯一性)。如何修改mac地址呢?一个方法就是直接修改网卡上烧制的mac地址,自己烧制。这个基本不靠谱,失误性也高。另一个方法就是修改注册表中的mac地址,因为网络中访问的mac地址都是访问的注册表中的mac地址,不会直接访问网卡。这个比较简单直接。
- 为什么有了ip地址,还要mac地址?这个问题很关键,就像是我有驾驶证了你非要让我提供身份证。这个涉及一些历史问题,因为一开始没有互联网的时候就只有mac地址,还不存在ip地址。后来互联网越来越大之后,发现mac地址找起来太麻烦,并且耗时也越来越久,就发明了ip地址。并且mac地址在一个局域网中还是很有用的,所以就两个一起存在了。详细的信息,大家可以参考https://www.zhihu.com/question/21546408。
Step4 进行tcp三次握手,建立tcp连接
简述一下,第三步我们找到了目标ip,并获得了服务器ip的mac地址。
此时浏览器就会请求和服务器连接,用来传输数据。
tcp 是稳定双向面向连接的,断开时也会分两边分别断开。
面向连接不是说tcp一个双方一直开着的通道,而是维持一个连接的状态,让它看起来有连接。
Step5 浏览器发送数据,等待服务器响应
第四步已经建立了连接,此时就要发送数据了。浏览器会对请求进行包装,包装成请求报文。请求报文的格式如下:
-
起始行:如 GET / HTTP/1.0 (请求的方法 请求的URL 请求所使用的协议)
-
头部信息:User-Agent Host等成对出现的值
-
请求主体
请求头部和主体之间有一个回车换行。如果是get请求,则没有主体部分,post请求有主体部分。当然里面还有些请求头部比较重要
Step6 服务器处理请求,并对请求做出响应
浏览器请求报文到达服务器之后,服务器接口会对请求报文进行处理,执行接口对应的代码,处理完成后响应客户端。由于http是无状态的,正常情况下,客户端收到响应后就会直接断开连接,然后一次http请求就完成了。但是http1.0有一个keep-alive的请求字段,可以在一定时间内不断开连接(有时时间甚至很长)。http1.1直接就默认开启了keep-alive选项。这导致了一个后果是服务器已经处理完了请求,但是客户端不会主动断开连接,这就导致服务器资源一直被占用。这时服务器就不得不自己主动断开连接,而主动断开连接的一方会出现TIME_WAIT,占用连接池,这就是产生SYN Flood攻击的原因。
此时有三种处理方式:
- 第一是客户端主动断开连接
第一种情况,如果服务器返回的数据都有确定的content-length属性,或者客户端知道服务器返回的内容终止,则客户端主动断开连接。
- 第二是服务器主动断开连接
第二种情况,服务器可以通过设置一个最大超市时间,可以主动断开tcp连接。
- 第三是对tcp连接经行设置。
第三种情况,调整t三个tcp参数:
- 第一个是:tcp_synack_retries 可以用他来减少重试次数;
- 第二个是:tcp_max_syn_backlog,可以增大syn连接数;
- 第三个是:tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。
Step7 浏览器收到服务器响应,得到html代码
其实你心里有疑问,这一步有什么好说的。其实这里面有很多需要注意的点。浏览器发出请求时,请求报文如下:
你需要关注一个报文头--accept。accept代表发送端(客户端)希望接受的数据类型,这是浏览器自动封装的请求头。如果服务器返回的content-type是accept中的任何一个,浏览器都能解析,并直接展示在网页上。如果服务器返回的content-type是其他类型,此时浏览器有三种处理状态:
- 正常显示。例如返回类型为text/javascript,浏览器能直接处理并展示。
- 下载。例如返回类型为application/octet-stream(二进制流,不知道下载文件类型),这种浏览器不能直接处理的,会被下载。
- 报错。当我们返回一个字符串hello world,却使用text/xml,格式时,浏览器不能正确解析,就会报错,并把报错信息呈现在网页中。
浏览器能直接处理很多种格式,并直接呈现在网页中,并不限于accept中规定的字段,具体有哪些,就需要自己亲自动手试试了。
附上一张content-type常用对照表地址:http content-type常用对照表
Step8 浏览器引擎渲染页面
获取到服务器相应之后,浏览器会根据相应的content-type字段对响应字符串进行解析。
能够解析并成功解析就显示,能够解析但解析错误就报错,不能解析就下载。
由于浏览器采用至上而下的方式解析,所以会先解析html,直到遇到外部样式和外部脚本。
这时会阻塞浏览器的解析,外部样式和外部脚本(在没有async、defer属性下)会并行加载,但是外部样式会阻塞外部脚本的执行,dom加载完毕,js脚本执行成功后dom树构建完成(DOMContentLoaded),之后就加载dom中引用的图片等静态资源。
(参考文章地址:http://blog.csdn.net/u014168594/article/details/52196460)
即:
html解析->外部样式、脚本加载->外部样式执行->外部脚本执行->html继续解析->dom树构建完成->加载图片->页面加载完成。
- 情况一:如果是动态脚本(即内联脚本)则不受样式影响,在解析到它时会执行。
如果脚本是动态加载,则不会影响DOMContentLoaded时间的触发,浏览器会等css加载完成后再加载图片,因为不确定图片的样式会如何。
- 情况二:外部样式后续外部脚本含有async属性(IE下为defer),外部样式不会阻塞该脚本的加载与执行
在外部样式执行完毕后,css附着于DOM,创建了一个渲染树(渲染树是一些被渲染对象的集)。
每个渲染对象都包含了与之对应的计算过样式的DOM对象,对于每个渲染元素来说,位置都经过计算,所以这里被叫做“布局
”。
然后将“布局”显示在浏览器窗口,称之为“绘制
”。
接着脚本的执行完毕后,DOM树构建完成。这时,可以触发DOMContentLoaded事件。DOMContentLoaded事件的触发条件是:在所有的DOM全部加载完毕并且JS加载执行后触发。
- 要点一:CSS样式表会阻塞图片的加载,如果想让图片尽快加载,就不要给图片使用样式,比如宽高采用标签属性即可。
- 要点二:脚本不会阻塞图片的加载
最后页面加载完成,页面load。
总结一下:
- 运维人员需要处理页面缓存、cdn及keep-alive引起的连接池占用等问题;
- 后端人员需要处理代码逻辑、缓存、传输优化、报错等问题;
- 前端人员需要做好前端性能优化和配合运维、后端做好借口调试,缓存处理等问题。
所以,无论是前端、后台、运维都应该很清楚整个流程中的每一步,才能在配合时,得心应手,才能在出现问题时,快速准确的定位问题解决问题,才能在需要优化时,迅速完整的给出方案。
1.3 HTTP请求和响应详解
1.3.1 客户端请求消息
客户端请求消息
,客户端发送一个HTTP请求
到服务器的请求消息
,包括4个部分:
- 请求行(request line)
请求报文的第一行,用来说明以什么方式请求、请求的地址和HTTP版本
- 请求头部(header)
每个头部字段都包含一个名字和值,二者之间采用“:”连接,如:Connection:Keep-Alive
- 空行
- 请求数据
请求的主体根据不同的请求方式请求主体不同
1.3.2 服务器响应消息
HTTP响应也由4个部分组成,分别是:
- 状态行
由HTTP版本、响应状态码、响应状态描述;如:HTTP/1.1 200 OK
- 消息报头(响应报文头部)
使用关键字和值表示,二者使用“:”隔开;如:Content-Type:text/html
-
空行
-
响应正文
请求空行之后就是请求内容
1.4 HTTP协议/版本的发展历程
- HTTP/0.9:1991年发布,极其简单,只有一个get命令
- HTTP/1.0:1996年5月发布,增加了大量内容
HTTP 1.0 定义了3种请求方法: GET, POST 和 HEAD方法。
- HTTP/1.1:1997年1月发布,进一步完善HTTP协议,是目前最流行的版本
HTTP1.1 新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
- SPDY :2009年谷歌发布SPDY协议,主要解决HTTP/1.1效率不高的问题
- HTTP/2 :2015年借鉴SPDY的HTTP/2发布
2 HTTP/1.0 [1991]
3 HTTP/1.1 [1996]【当前浏览器与服务器的主流选择/默认选择】
3.1 HTTP/1.0 与 HTTP/1.1的区别
3.1.1 缓存处理
- HTTP/1.0 使用 Pragma:no-cache + Last-Modified/If-Modified-Since来作为缓存判断的标准
- HTTP/1.1 引入了更多的缓存控制策略:Cache-Control、Etag/If-None-Match等
3.1.2 错误状态管理
- HTTP/1.1新增了24个错误状态响应码
如:
- 409(Conflict)表示请求的资源与资源的当前状态发生冲突
- 410(Gone)表示服务器上的某个资源被永久性的删除。
3.1.3 范围请求
- HTTP/1.1在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是
206
(Partial Content
),这样就方便了开发者自由的选择以便于充分利用带宽和连接,支持断点续传
3.1.4 Host头
- HTTP1.0
HTTP1.0 认为每台服务器都绑定一个唯一的IP地址。
因此,请求消息中的URL并没有传递主机名(hostname)。
但随着虚拟主机技术
的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。
- HTTP1.1
HTTP/1.1 的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(
400 Bad Request
)。
有了Host字段,就可以将请求发往同一台服务器上的不同网站,为虚拟主机的兴起打下了基础
3.1.5 持久连接与管道机制
- HTTP/1.1 最大的变化就是引入了
持久连接
(persistent connection
),在HTTP/1.1中默认开启Connection: keep-alive
即 :
TCP连接
默认不关闭,可以被多个HTTP请求复用
客户端和服务器发现对方一段时间没有活动,就可以主动关闭连接。
不过,规范的做法是,客户端在最后一个请求时,发送Connection: close
,明确要求服务器关闭TCP连接。
- HTTP/1.1 中引入了
管道机制
(pipelining
),即在同一个TCP连接中,客户端可以同时发送多个HTTP请求
3.1.6 请求方法
- HTTP1.0 定义了3种请求方法:
GET
/POST
/HEAD
- HTTP1.1 新增了5种请求方法:
OPTIONS
/PUT
/DELETE
/TRACE
/CONNECT
3.2 HTTP/1.1的缺点
3.2.1 TCP队头阻塞问题
HTTP/1.1 的持久连接
和管道机制
允许复用TCP连。
在一个TCP连接中,也可以同时发送多个请求,但是所有的数据通信都是按次序完成的,服务器只有处理完一个回应,才会处理下一个回应。
比如: 客户端需要A、B两个资源,管道机制允许浏览器同时发出A请求和B请求,但服务器还是按照顺序,先回应A请求,完成后再回应B请求,这样如果前面的回应特别慢,后面就会有很多请求排队等着,这称为"
队头阻塞
(Head-of-line blocking)"
4 HTTP/2 [2015]
HTTP/2以Google发布的SPDY协议为基础,于2015年发布。
它不叫HTTP/2.0,因为标准委员会不打算再发布子版本了,下一个新版本将是HTTP/3。
HTTP/2协议只在HTTPS环境下才有效,升级到HTTP/2,必须先启用HTTPS。
4.0 HTTP/2 主要特点
HTTP/2解决了HTTP/1.1的性能问题,主要特点如下:
4.0.1 二进制分帧
- HTTP/1.1 的头信息是文本(ASCII编码),数据体可以是文本,也可以是二进制;
- HTTP/2 头信息和数据体都是二进制,统称为“帧”:头信息帧和数据帧;
4.0.2 多路复用(双工通信)
通过单一的 HTTP/2 连接发起多重的请求-响应消息,即在一个连接里,客户端和浏览器都可以同时发送多个请求和响应,而不用按照顺序一一对应,这样避免了“队头堵塞”。
HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧,这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
4.0.3 数据流(stream)
因为 HTTP/2 的数据包是不按顺序发送的,同一个连接里面连续的数据包,可能属于不同的回应。因此,必须要对数据包
做标记,指出它属于哪个回应。
HTTP/2 将每个请求或回应的所有数据包,称为一个数据流
(stream
)。
每个数据流都有一个独一无二的编号。数据包发送的时候,都必须标记数据流ID,用来区分它属于哪个数据流。
另外还规定,客户端
发出的数据流,ID一律为奇数
,服务器
发出的,ID为偶数。
数据流发送到一半的时候,客户端和服务器都可以发送信号(RST_STREAM帧),取消这个数据流。
HTTP/1.1
取消数据流的唯一方法,就是关闭TCP连接
。
这就是说,HTTP/2 可以取消某一次请求,同时保证TCP连接还打开着,可以被其他请求使用。
客户端还可以指定数据流的优先级。优先级越高,服务器就会越早回应。
4.0.4 首部压缩
HTTP 协议不带有状态,每次请求都必须附上所有信息。
所以,请求的很多字段都是重复的,一模一样的内容,每次请求都必须附带,这会浪费很多带宽,也影响速度。
HTTP/2 对这一点做了优化,引入了头信息压缩机制
(header compression
)。
一方面,头信息压缩后再发送(SPDY 使用的是通用的DEFLATE 算法
,而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法)。
另一方面,客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
4.0.5 服务端推送
HTTP/2 允许服务器未经请求,主动向客户端发送资源,这叫做服务器推送
(server push
)。
常见场景是客户端请求一个网页,这个网页里面包含很多静态资源。
正常情况下,客户端必须收到网页后,解析HTML源码,发现有静态资源,再发出静态资源请求。
其实,服务器可以预期到客户端请求网页后,很可能会再请求静态资源,所以就主动把这些静态资源随着网页一起发给客户端了。
4.1 HTTP/2 辉煌不在?
虽然HTTP/2标准在2015年5月就以RFC 7540
正式发表了,并且多数浏览器在2015年底就支持了。
但是,真正被广泛使用起来要到2018年左右,但是也是在2018年,11月IETF给出了官方批准,认可HTTP-over-QUIC成为HTTP/3。
2018年的时候,我写过一篇文章介绍《HTTP/2到底是什么?》,那时候HTTP/2还是个新技术,刚刚开始有软件支持,短短两年过去了,现在HTTP/3已经悄然而至了。
根据W3Techs的数据,截至2019年6月,全球也仅有36.5%的网站支持了HTTP/2。所以,可能很多网站还没开始支持HTTP/2,HTTP/3就已经来了。
所以,对于很多网站来说,或许直接升级HTTP/3是一个更加正确的选择。
4.2 回顾 HTTP/2
在阅读本文之前,强烈建议大家先阅读下《HTTP/2到底是什么?》这篇文章,这里面介绍了HTTP的历史,介绍了各个版本的HTTP协议的诞生的背景。
当你读到这里的时候,我默认大家对HTTP/2有了一定的基本了解。
我们知道,HTTP/2的诞生,主要是为了解决HTTP/1.1
中的效率问题,HTTP/2中最核心的技术就是多路复用技术,即允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。
同时还实现了二进制分帧、header压缩、服务端推送等技术。
从
HTTP/1.0
诞生,一直到HTTP/2
,在这24年里,HTTP
协议已经做过了三次升级,但是有一个关键的技术点是不变的,那就是这所有的HTTP协议,都是基于TCP协议
实现的。
流水的HTTP,铁打的TCP。这是因为相对于UDP协议,TCP协议更加可靠。
虽然在HTTP/1.1
的基础上推出HTTP/2
大大的提升了效率,但是还是有很多人认为这只是个"临时方案
",这也是为什么刚刚推出没多久,业内就开始大力投入HTTP/3
的研发与推广了。
而这背后的深层次原因也正是因为他还是基于TCP协议
实现的。TCP协议虽然更加可靠,但是还是存在着一定的问题,接下来具体分析下。
4.3 HTTP/2 问题 : 队头阻塞问题
队头阻塞
翻译自英文head-of-line blocking
,这个词并不新鲜,因为早在HTTP/1.1
时代,就一直存在着队头阻塞
的问题。
但是很多人在一些资料中会看到有论点说HTTP/2
解决了队头阻塞的问题。但是这句话只对了一半。
只能说
HTTP/2
解决了HTTP的队头阻塞问题
,但是并没有解决TCP队头阻塞问题
!
如果大家对于HTTP的历史有一定的了解的话,就会知道。
4.3.1 HTTP/1.1 引入【持久连接/请求管道(keep-alive)】 => 仍遗留【HTTP队头阻塞问题】
HTTP/1.1相比较于HTTP/1.0来说,最主要的改进就是引入了持久连接(keep-alive)。
所谓的持久连接
就是:
在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。
引入了持久连接
之后,在性能方面,HTTP协议有了明显的提升。
另外,HTTP/1.1
允许在持久连接
上使用请求管道
,是相对于持久连接的又一性能优化。
所谓请求管道
,就是在HTTP响应到达之前,可以将多条请求放入队列,当第一条HTTP请求通过网络流向服务器时,第二条和第三条请求也可以开始发送了。在高时延网络条件下,这样做可以降低网络的环回时间,提高性能。
但是,对于管道连接
还是有一定的限制和要求的,其中一个比较关键的就是:
服务端必须按照与请求相同的顺序回送HTTP响应。
这也就意味着:
如果一个响应返回发生了延迟,那么其后续的响应都会被延迟,直到队头的响应送达。这就是所谓的HTTP队头阻塞。
4.3.2 HTTP/2 多路复用(引入【帧/消息/数据流】): 解决【HTTP队头阻塞】 => 仍依赖【TCP队头阻塞】
但是HTTP队头阻塞的问题在HTTP/2
中得到了有效的解决。
HTTP/2
废弃了管道化
的方式,而是创新性的引入了帧
、消息
和数据流
等概念。
客户端和服务器可以把 HTTP 消息
分解为互不依赖的帧
,然后乱序发送
,最后再在另一端把它们重新组合起来。
因为没有顺序了,所以就不需要阻塞了,就有效的解决了HTTP队头阻塞
的问题。
但是,HTTP/2
仍然会存在TCP队头阻塞的问题,那是因为HTTP/2
其实还是依赖TCP协议
实现的。
TCP传输过程
中会把数据拆分为一个个按照顺序排列的数据包,这些数据包通过网络传输到了接收端,接收端再按照顺序将这些数据包组合成原始数据,这样就完成了数据传输。
但是如果其中的某一个数据包没有按照顺序到达,接收端会一直保持连接等待数据包返回,这时候就会阻塞后续请求。这就发生了TCP队头阻塞。
HTTP/1.1
的管道化持久连接
,也是使得同一个TCP连接
可以被多个HTTP
连接使用,但是HTTP/1.1
中规定一个域名可以有6个TCP连接
。
而HTTP/2
中,同一个域名
只是用一个TCP连接
。
所以,在HTTP/2
中,TCP队头阻塞造成的影响会更大,因为HTTP/2
的多路复用技术
使得多个请求其实是基于同一个TCP连接
的,那如果某一个请求造成了TCP队头阻塞,那么多个请求都会受到影响。
4.4 TCP握手时长
一提到TCP协议,大家最先想到的一定是它的三次握手
与四次关闭
的特性。
因为TCP
是一种可靠通信协议
,而这种可靠
就是靠三次握手
实现的,通过三次握手
,TCP
在传输过程中可以保证接收方收到的数据是完整
,有序
,无差错
的。
但是,问题是三次握手是需要消耗时间的,这里插播一个关于网络延迟
的概念。
网络延迟
又称为 RTT
(Round Trip Time
)。
- 它是指一个请求从客户端浏览器发送一个请求数据包到服务器,再从服务器得到响应数据包的这段时间。
RTT
是反映网络性能的一个重要指标。
我们知道,TCP三次握手
的过程客户端和服务器之间需要交互三次,那么也就是说需要消耗1.5 RTT。
另外,如果使用的是安全的HTTPS协议
,就还需要使用TLS协议
进行安全数据传输,这个过程又要消耗1个RTT(TLS不同版本的握手机制不同,这里按照最小的消耗来算)
那么也就是说,一个纯HTTP/2的连接,需要消耗1.5个RTT,如果是一个HTTPS连接,就需要消耗3-4个RTT。
而具体消耗的时长根据服务器和客户端之间的距离则不尽相同,如果比较近的话,消耗在100ms以内,对于用来说可能没什么感知,但是如果一个RTT的耗时达到300-400ms,那么,一次连接建立过程总耗时可能要达到一秒钟左右,这时候,用户就会明显的感知到网页加载很慢。
4.5 升级TCP是否可行?
4.5.1 网络中间设备僵化 => 协议僵化
基于上面我们提到的这些问题,很多人提出来说:既然TCP存在这些问题,并且我们也知道这些问题的存在,甚至解决方案也不难想到,为什么不能对协议本身做一次升级,解决这些问题呢?
其实,这就涉及到一个"协议僵化
"的问题。
这样讲,我们在互联网上浏览数据的时候,数据的传输过程其实是极其复杂的。
我们知道的,想要在家里使用网络有几个前提,首先我们要通过运行商开通网络,并且需要使用路由器,而路由器就是网络传输过程中的一个中间设备。
中间设备是指插入在数据终端和信号转换设备之间,完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。
在我们看不到的地方,这种中间设备还有很多很多,一个网络需要经过无数个中间设备的转发才能到达终端用户。
如果TCP协议需要升级,那么意味着需要这些中间设备都能支持新的特性,我们知道路由器我们可以重新换一个,但是其他的那些中间设备呢?尤其是那些比较大型的设备呢?更换起来的成本是巨大的。
而且,除了中间设备之外,操作系统也是一个重要的因素,因为TCP协议需要通过操作系统内核来实现,而操作系统的更新也是非常滞后的。
所以,这种问题就被称之为"中间设备僵化
",也是导致"协议僵化
"的重要原因。这也是限制着TCP协议更新的一个重要原因。
所以,近些年来,由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用!
4.6 放弃TCP?
上面提到的这些问题的根本原因都是因为HTTP/2是基于TPC实现导致的,而TCP协议自身的升级又是很难实现的。
那么,剩下的解决办法就只有一条路,那就是放弃TCP协议。
放弃TCP的话,就又有两个新的选择,是使用其他已有的协议,还是重新创造一个协议呢?
看到这里,聪明的读者一定也想到了,创造新的协议一样会受到中间设备僵化的影响。近些年来,因为在互联网上部署遭遇很大的困难,创造新型传输层协议的努力基本上都失败了!
所以,想要升级新的HTTP协议,那么就只剩一条路可以走了,那就是基于已有的协议做一些改造和支持,UDP
就是一个绝佳的选择了。
4.Y 小结
因为HTTP/2
底层是采用TCP协议
实现的,虽然解决了HTTP队头阻塞
的问题,但是对于TCP队头阻塞
的问题却无能为力。
TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包,这些数据包通过网络传输到了接收端,接收端再按照顺序将这些数据包组合成原始数据,这样就完成了数据传输。
但是如果其中的某一个数据包没有按照顺序到达,接收端会一直保持连接等待数据包返回,这时候就会阻塞后续请求。这就发生了 TCP队头阻塞
。
另外,TCP这种可靠传输是靠三次握手
实现的,TCP三次握手的过程客户端和服务器之间需要交互三次,那么也就是说需要消耗1.5 RTT。如果是HTTPS那么消耗的RTT就更多。
而因为很多中间设备
比较陈旧,更新换代成本巨大,这就导致TCP协议
升级或者采用新的协议基本无法实现。
所以,HTTP/3
选择了一种新的技术方案,那就是基于UDP
做改造,这种技术叫做QUIC
。
那么问题来了,HTTP/3
是如何使用的UDP呢?做了哪些改造?如何保证连接的可靠性?UDP协议就没有僵化的问题了吗?
4.X 参考文献
- HTTP/2做错了什么?刚刚辉煌2年就要被弃用了!? - 1024搜
- https://http3-explained.haxx.se/
- https://baike.baidu.com/item/中间设备/3688874
- https://time.geekbang.org/column/article/150159
- https://juejin.cn/post/6844903853985366023
- https://time.geekbang.org/column/article/279164
K HTTPS
K.1 简述
HTTPS可以说是安全版的HTTP,HTTPS基于安全SSL/TLS(安全套接层Secure Sockets Layer
/安全传输层Transport Layer Security
)层
即: 在传统的HTTP和TCP之间加了一层用于加密解密的SSL/TLS层。HTTP默认使用80端口,HTTPS默认使用443端口。
不使用SSL/TLS的HTTP通信,所有信息明文传播,会带来三大风险:
-
窃听风险:第三方可以获取通信内容;
-
篡改风险:第三方可以修改通信内容;
-
冒充风险:第三方可以冒充他人进行通信。
SSL/TLS协议是为了解决这三大风险而设计的,以期达到:
- 信息加密传输:第三方无法窃听;
- 校验机制:一旦被篡改,通信双方会立刻发现;
- 身份证书:防止身份被冒充。
K.2 SSL/TLS发展
- SSL/1.0:1994年NetScape公司设计,未发布;
- SSL/2.0:1995年NetScape公司发布,但存在严重漏洞;
- SSL/3.0:1996年NetScape公司发布,得到大规模应用;
- TLS/1.0:1999年互联网标准化组织(ISOC)接替NetScape公司,发布SSL的升级版TLS/1.0;
- TLS/1.1:2006年发布;
- TLS/1.2:2008年发布;
- TLS/1.2修订版:2011年发布。
目前,应用最广泛的是 TLS/1.0 和 SSL/3.0,且主流浏览器已实现 TLS/1.2的支持。
K.3 SSL/TLS运行机制
SSL/TLS的基本思路是公钥加密法
:
- 客户端先向服务器索要并验证公钥,
- 然后,客户端用公钥加密传输来协商生成“对话秘钥”(非对称加密),双方采用“对话秘钥”进行加密通信(对称加密)。
通信过程如下:
- 客户端发出请求:给出支持的协议版本、支持的加密方法(如RSA公钥加密)以及一个客户端生成的随机数(Client random);
- 服务端回应:确认双方通信的协议版本、加密方法,并给出服务器证书以及一个服务器生成的随机数(Server random);
- 客户端回应:客户端确认证书有效,取出证书中的公钥,然后生成一个新的随机数(Premaster secret),使用公钥加密这个随机数,发送给服务端;
- 服务端回应:服务端使用自己的私钥解密客户端发来的随机数(Premaster secret),客户端和服务端根据约定的加密方法,使用三个随机数,生成“对话秘钥”;
- 会话通信:客户端和服务端使用“对话秘钥”加密通信,这个过程完全使用普通的HTTP协议,只不过用“会话秘钥”加密内容。
前四步称为
握手阶段
,用于客户端和服务端建立连接
和交换参数
。
K.4 HTTPS协议的特点
-
缓存:只要在HTTP头中使用特定命令,就可以缓存HTTPS
-
延迟:
- HTTP耗时 = TCP握手
- HTTPS耗时 = TCP握手 + SSL握手。
SSL握手
耗时大概是TCP握手
耗时的三倍左右。
Q 相关面试问题
Q2 HTTP 与 HTTPS 的区别?
Q3 常用HTTP状态码?
HTTP状态码表示客户端HTTP请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。
状态码的类别:
Q4 GET和POST区别?
[1] HTTP 协议的
请求方法
HTTP协议中定义了浏览器和服务器进行交互的不同方法,基本方法有4种,分别是GET,POST,PUT,DELETE。这四种方法可以理解为,对服务器资源的查,改,增,删。
- GET:从服务器上获取数据,也就是所谓的查,仅仅是获取服务器资源,不进行修改。
- POST:向服务器提交数据,这就涉及到了数据的更新,也就是更改服务器的数据。
- PUT:英文含义是放置,也就是向服务器新添加数据,就是所谓的增。
- DELETE:从字面意思也能看出,这种方式就是删除服务器数据的过程。
[1] HTTP 协议中
GET
与POST
的区别?
- Get是
不安全
的。
因为在传输过程,数据被放在请求的URL中;Post的所有操作对用户来说都是不可见的。 但是这种做法也不时绝对的,大部分人的做法也是按照上面的说法来的,但是也可以在get请求加上 request body,给 post请求带上 URL 参数。
- Get请求提交的url中的数据
最多只能是2048字节
这个限制是浏览器或者服务器给添加的,http协议并没有对url长度进行限制,目的是为了保证服务器和浏览器能够正常运行,防止有人恶意发送请求。Post请求则没有大小限制。
- Get限制
Form表单的数据集的值
必须为ASCII字符
;而Post支持整个ISO10646字符集
。 - Get
执行效率
却比Post方法好。Get是form提交的默认方法。 - GET产生一个
TCP数据包
;POST产生2个TCP数据包
。
对于GET
方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
而对于POST
,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
Q5 什么是对称加密与非对称加密?
- 对称密钥加密是指加密和解密使用
同一个密钥
的方式。这种方式存在的最大问题就是密钥发送问题,
即:如何安全地将密钥发给对方
- 而
非对称加密
是指使用一对非对称密钥,即公钥
和私钥
,公钥可以随意发布,但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理,对方接收到加密信息后,使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥,所以可以保证安全性;但是和对称加密比起来,非常的慢
Q6 什么是HTTP2?
HTTP2
可以提高了网页的性能。
在 HTTP1
中浏览器限制了同一个域名
下的请求数量(Chrome 下一般是六个),当在请求很多资源的时候,由于队头阻塞当浏览器达到最大请求数量时,剩余的资源需等待当前的六个请求完成后才能发起请求。
HTTP2
中引入了多路复用
的技术,这个技术可以只通过一个 TCP 连接
就可以传输所有的请求数据。
多路复用
可以绕过浏览器限制
同一个域名下的请求数量的问题,进而提高了网页的性能。
Q7 Session、Cookie和Token的主要区别?
-
HTTP协议
本身是无状态的。什么是无状态呢,即服务器无法判断用户身份。 -
什么是cookie?
cookie是由Web服务器保存在用户浏览器上的小文件(key-value格式),包含用户相关的信息。
客户端向服务器发起请求,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。
客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户身份。
- 什么是Session?
session是·依赖Cookie·实现的。session是服务器端的用户会话对象
session 是浏览器和服务器会话过程中,服务器分配的一块储存空间。
服务器默认为浏览器在cookie
中设置sessionid
,浏览器在向服务器请求过程中传输 cookie 包含 sessionid ,服务器根据 sessionid 获取出会话中存储的信息,然后确定会话的身份信息。
- cookie与session区别?
- 存储位置与安全性:cookie数据存放在客户端上,
安全性较差
,session数据放在服务器上,安全性相对更高;- 存储空间:单个cookie保存的数据
不能超过4K
,很多浏览器都限制一个站点最多保存20个cookie,session无此限制- 占用服务器资源:session一定时间内保存在服务器上,当访问增多,占用服务器性能,考虑到服务器性能方面,应当使用cookie。
Q8 什么是Token?
Token的引入:Token是在客户端频繁向服务端请求数据,服务端频繁的去数据库查询用户名和密码并进行对比,判断用户名和密码正确与否,并作出相应提示,在这样的背景下,Token便应运而生。
Token的定义:Token是服务端生成的一串字符串,以作客户端进行请求的一个令牌,当第一次登录后,服务器生成一个Token便将此Token返回给客户端,以后客户端只需带上这个Token前来请求数据即可,无需再次带上用户名和密码。
使用Token的目的:Token的目的是为了减轻服务器的压力,减少频繁的查询数据库,使服务器更加健壮。
Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证,服务端认证成功,那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位
Q9 session与token区别?
- session机制存在服务器压力增大,CSRF跨站伪造请求攻击,扩展性不强等问题;
- session存储在服务器端,token存储在客户端
- token提供认证和授权功能,作为身份认证,token安全性比session好;
- session这种会话存储方式方式只适用于客户端代码和服务端代码运行在同一台服务器上,token适用于项目级的前后端分离(前后端代码运行在不同的服务器下)
Q10 Servlet是线程安全的吗?
Servlet不是线程安全的,多线程并发的读写会导致数据不同步的问题。
解决的办法是尽量不要定义name属性,而是要把name变量分别定义在doGet()
和doPost()
方法内。虽然使用synchronized(name)语句块可以解决问题,但是会造成线程的等待,不是很科学的办法。
注意:多线程的并发的读写Servlet类属性会导致数据不同步。但是如果只是并发地读取属性而不写入,则不存在数据不同步的问题。因此Servlet里的只读属性最好定义为final类型的。
Q11 Servlet接口中有哪些方法?
在Java Web程序中,Servlet主要负责接收用户请求HttpServletRequest,在doGet(),doPost()中做相应的处理,并将回应HttpServletResponse反馈给用户。Servlet可以设置初始化参数,供Servlet内部使用。
Servlet接口定义了5个方法,其中前三个方法与Servlet生命周期相关:
- void init(ServletConfig config) throws ServletException
- void service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOException
- void destory()
- java.lang.String getServletInfo()
- ServletConfig getServletConfig()
Q12 Servlet的生命周期?
-
Web容器加载Servlet并将其实例化后,Servlet生命周期开始,容器运行其
init()
方法进行Servlet的初始化; -
请求到达时调用Servlet的
service()
方法,service()方法会根据需要调用与请求对应的doGet
或doPost
等方法; -
当服务器关闭或项目被卸载时服务器会将Servlet实例销毁,此时会调用Servlet的
destroy()
方法。
init方法和destory方法只会执行一次,service方法客户端每次请求Servlet都会执行。
Servlet中有时会用到一些需要初始化与销毁的资源。因此,可以把初始化资源的代码放入init
方法中,销毁资源的代码放入destroy
方法中,这样就不需要每次处理客户端的请求都要初始化与销毁资源。
Q13 如果客户端禁止 cookie 能实现 session 还能用吗?
- Cookie 与 Session,一般认为是两个独立的东西,Session采用的是在服务器端保持状态的方案,而Cookie采用的是在客户端保持状态的方案。
- 但为什么禁用Cookie就不能得到Session呢?因为Session是用
Session ID
来确定当前对话所对应的服务器Session,而Session ID是通过Cookie来传递的,禁用Cookie相当于失去了Session ID,也就得不到Session了。
假定用户关闭Cookie的情况下使用Session,其实现途径有以下几种:
- 手动通过URL传值、隐藏表单传递
Session ID
。 - 用文件、数据库等形式保存
Session ID
,在跨页过程中手动调用。
X 参考文献
本文链接: https://www.cnblogs.com/johnnyzen
关于博文:评论和私信会在第一时间回复,或直接私信我。
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
日常交流:大数据与软件开发-QQ交流群: 774386015 【入群二维码】参见左下角。您的支持、鼓励是博主技术写作的重要动力!
一个简单网络爬虫示例(转载)
在学生时期,可能听到网络爬虫这个词会觉得很高大上,但是它的简单实现可能学生都不难懂。
网络爬虫应用,就是把整个互联网真的就当做一张网,像蜘蛛网那样,应用就像一个虫子,在网上面按照一定的规则爬动。
现在互联网应用最广的就是http(s)协议了,本文例子就是基于使用http(s)协议的,只作为示例,不涉及复杂的算法(实际上是最重要的)。
设计思路:
程序入口从一个或多个url开始,通过http(s)获取url的内容,对获取到内容处理,获取内容中需要爬取的信息,获取到内容中的url链接,再重复以上步骤。
不多说,详情看代码已经注释:
/**
* 功能概要:主程序
*
* @author hwz
*/
public class MainApp {
private Integer corePoolSize = 10;
private Integer maxPoolSize = 20;
private ThreadPoolExecutor executor;
/** 工作队列 */
private SpiderQueue workQueue;
public void start(String url) throws Exception {
//初始化线程池
LinkedBlockingDeque<Runnable> executorQueue = new LinkedBlockingDeque<Runnable>(maxPoolSize);
executor = new ThreadPoolExecutor(corePoolSize, maxPoolSize, 60L, TimeUnit.SECONDS,
executorQueue);
workQueue = new SpiderQueue(1024);
SpiderUrl spiderUrl = new SpiderUrl(url, 0);
try {
workQueue.add(spiderUrl);
}
catch (Exception e) {
System.out.println("insert url into workQueue error,url=" + url);
e.printStackTrace();
}
//提交第一个执行任务
executor.submit(new SimpleSpider(workQueue, "thread-" + "main"));
int i=0;
int idle = 0;
while(true) {
//判断是否增加更多线程执行任务
if (workQueue.size() > 20 && executor.getActiveCount() < maxPoolSize) {
idle = 0;
System.out.println("submit new thread,workQueue.size=" + workQueue.size() +
",executorQueue.activeCount=" + executor.getActiveCount() + ",i=" + i);
executor.submit(new SimpleSpider(workQueue, "thread-" + i++));
Thread.sleep(500);
}
else if (workQueue.size() == 0){
idle++;
System.out.println("main method, idle times=" + idle);
//主线程空闲20次,结束运行
if (idle > 20) {
System.out.println("main method, idle times=" + idle + ",end!");
break;
}
Thread.sleep(1000);
}
else {
Thread.sleep(2000);
}
}
System.out.println("End!,workQueue.size=" + workQueue.size() +
",executorQueue.activeCount=" + executor.getActiveCount() + ",executorQueue.CompletedTaskCount" +
executor.getCompletedTaskCount() + ",i=" + i);
workQueue.printAll();
executor.shutdown();
System.exit(0);
}
public static void main(String[] args) throws Exception {
MainApp app = new MainApp();
app.start("http://www.csdn.net/");
}
}
/**
*
* 功能概要:自定义爬虫工作同步队列,使用ArrayList实现
*
* @author hwz
*/publicclass SpiderQueue {/** 存储器 */private List<SpiderUrl> queue;
publicSpiderQueue(int size) {
queue = new ArrayList<SpiderUrl>(size);
}
publicsynchronizedvoidadd(SpiderUrl spiderUrl) {
queue.add(spiderUrl);
}
publicsynchronized SpiderUrl poll() {
if (queue.isEmpty()) {
returnnull;
}
//控制台打印结果,方便查看
SpiderUrl spiderUrl = queue.remove(0);
System.out.println("SpiderQueue,poll,SpiderUrl=" + spiderUrl.toString() + ",remain size=" + queue.size());
return spiderUrl;
}
publicsynchronized SpiderUrl peek() {
if (queue.isEmpty()) {
returnnull;
}
return queue.get(0);
}
publicsynchronizedbooleanisExsit(SpiderUrl spiderUrl) {
return queue.contains(spiderUrl);
}
publicsynchronizedintsize() {
return queue.size();
}
publicvoidprintAll() {
System.out.println("Enter printAll.");
for (SpiderUrl spiderUrl : queue) {
System.out.println(spiderUrl);
}
}
}
/**
*
* 功能概要:爬虫工作的url
*
* @author hwz
*/publicclass SpiderUrl {/** http(s) url */private String url;
/** 该url是入口url的第几层 */privateint deep;
publicSpiderUrl(String url, int deep) {
this.url = url;
this.deep = deep;
}
public String getUrl() {
return url;
}
publicvoidsetUrl(String url) {
this.url = url;
}
publicintgetDeep() {
return deep;
}
publicvoidsetDeep(int deep) {
this.deep = deep;
}
@Overridepublicbooleanequals(Object obj) {
if (!(obj instanceof SpiderUrl)) {
returnfalse;
}
SpiderUrl oth = (SpiderUrl) obj;
returnthis.url.equals(oth.getUrl());
}
@OverridepublicinthashCode() {
return url.hashCode();
}
@Overridepublic String toString() {
return getClass().toString() + "[url:" + url + ",deep:" + deep +"]";
}
}
/**
*
* 功能概要:爬虫工作类,主要实现类
*
* @author hwz
*/publicclass SimpleSpider implements Runnable{private String threadName;
private SpiderUrl url;
private SpiderQueue workQueue;
publicSimpleSpider(SpiderQueue workQueue, String threadName) {
this.workQueue = workQueue;
this.threadName = threadName;
}
@Overridepublicvoidrun() {
System.out.println(threadName + " start run");
//连续空闲10次循环,结束任务int idle = 0;
while (idle < 10) {
url = workQueue.poll();
if (url != null) {
//url 解析
parseUrl(url);
idle = 0;
}
else {
System.out.println(threadName + " idle...,times=" + idle++);
try {
Thread.sleep(1000);
}
catch (InterruptedException e) {
e.printStackTrace();
}
}
}
System.out.println(threadName + " end run...");
}
/**
* url解析
* @param url
* @return void
*/privatevoidparseUrl(SpiderUrl url) {
if (url == null) {
return;
}
try {
int deep = url.getDeep() + 1;
URL netUrl = new URL(url.getUrl());
URLConnection connection = netUrl.openConnection();
String contentType = connection.getContentType();
//获取内容
String resource = getResource(connection);
//获取标题
String title = getTitle(resource);
//获取链接
List<String> urls = getUrls(resource);
System.out.println(threadName + ",parseUrl url=" + url + ",contentType=" + contentType + ",title=" + title + ",urls=" + urls);
//控制爬取链接层数,如果获取到的url全部加入工作队列,将会是指数级增加,最后程序挂掉if (deep < 3) {
SpiderUrl newUrl;
for (String u : urls) {
newUrl = new SpiderUrl(u,deep);
if(!workQueue.isExsit(newUrl)) {
workQueue.add(newUrl);
}
}
}
}
catch (IOException e) {
e.printStackTrace();
}
}
/**
* 读取http url 内容
* @param connection
* @return
* @return String
*/private String getResource(URLConnection connection) {
if (connection == null) {
returnnull;
}
StringBuilder sb = new StringBuilder();
try {
InputStream inputStream = connection.getInputStream();
InputStreamReader isr = new InputStreamReader(inputStream, "UTF-8");
int input;
while ( (input = isr.read()) != -1) {
sb.append((char)input);
}
}
catch (IOException e) {
System.out.println(threadName + ",get resource error,connection=" + connection);
}
return sb.toString();
}
/**
* 从url内容获取标题
* @param content
* @return
* @return String
*/private String getTitle(String content) {
if (content == null) {
returnnull;
}
Pattern pattern = Pattern.compile("(<title>.{1,}</title>)");
Matcher matcher = pattern.matcher(content);
String title = null;
if (matcher.find()) {
title = matcher.group(0).replaceAll("<title>", "").replaceAll("</title>", "");
}
return title;
}
/**
* 从url内容中获取存在的url链接
* @param content
* @return
* @return List<String>
*/private List<String> getUrls(String content) {
if (content == null) {
returnnull;
}
Pattern pattern = Pattern.compile("(<a.{1,}?href=[‘\"]?[a-zA-z]+:\\/\\/[^\\s]*?[\\s>]{1})");
Matcher matcher = pattern.matcher(content);
String a;
String lastChar;
List<String> links = new ArrayList<String>();
while (matcher.find()) {
a = matcher.group(0).replaceAll("<a.{1,}?href=[‘\"]?", "");
a = a.trim();
lastChar = a.substring(a.length()-1);
if (lastChar.equals("‘") || lastChar.equals("\"") || lastChar.equals(">")) {
a = a.substring(0,a.length()-1);
}
links.add(a);
}
return links;
}
}
在学生时期,可能听到网络爬虫这个词会觉得很高大上,但是它的简单实现可能学生都不难懂。
网络爬虫应用,就是把整个互联网真的就当做一张网,像蜘蛛网那样,应用就像一个虫子,在网上面按照一定的规则爬动。
现在互联网应用最广的就是http(s)协议了,本文例子就是基于使用http(s)协议的,只作为示例,不涉及复杂的算法(实际上是最重要的)。
设计思路:
程序入口从一个或多个url开始,通过http(s)获取url的内容,对获取到内容处理,获取内容中需要爬取的信息,获取到内容中的url链接,再重复以上步骤。
不多说,详情看代码已经注释:
/**
* 功能概要:主程序
*
* @author hwz
*/
public class MainApp {
private Integer corePoolSize = 10;
private Integer maxPoolSize = 20;
private ThreadPoolExecutor executor;
/** 工作队列 */
private SpiderQueue workQueue;
public void start(String url) throws Exception {
//初始化线程池
LinkedBlockingDeque<Runnable> executorQueue = new LinkedBlockingDeque<Runnable>(maxPoolSize);
executor = new ThreadPoolExecutor(corePoolSize, maxPoolSize, 60L, TimeUnit.SECONDS,
executorQueue);
workQueue = new SpiderQueue(1024);
SpiderUrl spiderUrl = new SpiderUrl(url, 0);
try {
workQueue.add(spiderUrl);
}
catch (Exception e) {
System.out.println("insert url into workQueue error,url=" + url);
e.printStackTrace();
}
//提交第一个执行任务
executor.submit(new SimpleSpider(workQueue, "thread-" + "main"));
int i=0;
int idle = 0;
while(true) {
//判断是否增加更多线程执行任务
if (workQueue.size() > 20 && executor.getActiveCount() < maxPoolSize) {
idle = 0;
System.out.println("submit new thread,workQueue.size=" + workQueue.size() +
",executorQueue.activeCount=" + executor.getActiveCount() + ",i=" + i);
executor.submit(new SimpleSpider(workQueue, "thread-" + i++));
Thread.sleep(500);
}
else if (workQueue.size() == 0){
idle++;
System.out.println("main method, idle times=" + idle);
//主线程空闲20次,结束运行
if (idle > 20) {
System.out.println("main method, idle times=" + idle + ",end!");
break;
}
Thread.sleep(1000);
}
else {
Thread.sleep(2000);
}
}
System.out.println("End!,workQueue.size=" + workQueue.size() +
",executorQueue.activeCount=" + executor.getActiveCount() + ",executorQueue.CompletedTaskCount" +
executor.getCompletedTaskCount() + ",i=" + i);
workQueue.printAll();
executor.shutdown();
System.exit(0);
}
public static void main(String[] args) throws Exception {
MainApp app = new MainApp();
app.start("http://www.csdn.net/");
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
/**
*
* 功能概要:自定义爬虫工作同步队列,使用ArrayList实现
*
* @author hwz
*/
public class SpiderQueue {
/** 存储器 */
private List<SpiderUrl> queue;
public SpiderQueue(int size) {
queue = new ArrayList<SpiderUrl>(size);
}
public synchronized void add(SpiderUrl spiderUrl) {
queue.add(spiderUrl);
}
public synchronized SpiderUrl poll() {
if (queue.isEmpty()) {
return null;
}
//控制台打印结果,方便查看
SpiderUrl spiderUrl = queue.remove(0);
System.out.println("SpiderQueue,poll,SpiderUrl=" + spiderUrl.toString() + ",remain size=" + queue.size());
return spiderUrl;
}
public synchronized SpiderUrl peek() {
if (queue.isEmpty()) {
return null;
}
return queue.get(0);
}
public synchronized boolean isExsit(SpiderUrl spiderUrl) {
return queue.contains(spiderUrl);
}
public synchronized int size() {
return queue.size();
}
public void printAll() {
System.out.println("Enter printAll.");
for (SpiderUrl spiderUrl : queue) {
System.out.println(spiderUrl);
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
/**
*
* 功能概要:爬虫工作的url
*
* @author hwz
*/
public class SpiderUrl {
/** http(s) url */
private String url;
/** 该url是入口url的第几层 */
private int deep;
public SpiderUrl(String url, int deep) {
this.url = url;
this.deep = deep;
}
public String getUrl() {
return url;
}
public void setUrl(String url) {
this.url = url;
}
public int getDeep() {
return deep;
}
public void setDeep(int deep) {
this.deep = deep;
}
@Override
public boolean equals(Object obj) {
if (!(obj instanceof SpiderUrl)) {
return false;
}
SpiderUrl oth = (SpiderUrl) obj;
return this.url.equals(oth.getUrl());
}
@Override
public int hashCode() {
return url.hashCode();
}
@Override
public String toString() {
return getClass().toString() + "[url:" + url + ",deep:" + deep +"]";
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
/**
*
* 功能概要:爬虫工作类,主要实现类
*
* @author hwz
*/
public class SimpleSpider implements Runnable{
private String threadName;
private SpiderUrl url;
private SpiderQueue workQueue;
public SimpleSpider(SpiderQueue workQueue, String threadName) {
this.workQueue = workQueue;
this.threadName = threadName;
}
@Override
public void run() {
System.out.println(threadName + " start run");
//连续空闲10次循环,结束任务
int idle = 0;
while (idle < 10) {
url = workQueue.poll();
if (url != null) {
//url 解析
parseUrl(url);
idle = 0;
}
else {
System.out.println(threadName + " idle...,times=" + idle++);
try {
Thread.sleep(1000);
}
catch (InterruptedException e) {
e.printStackTrace();
}
}
}
System.out.println(threadName + " end run...");
}
/**
* url解析
* @param url
* @return void
*/
private void parseUrl(SpiderUrl url) {
if (url == null) {
return;
}
try {
int deep = url.getDeep() + 1;
URL netUrl = new URL(url.getUrl());
URLConnection connection = netUrl.openConnection();
String contentType = connection.getContentType();
//获取内容
String resource = getResource(connection);
//获取标题
String title = getTitle(resource);
//获取链接
List<String> urls = getUrls(resource);
System.out.println(threadName + ",parseUrl url=" + url + ",contentType=" + contentType + ",title=" + title + ",urls=" + urls);
//控制爬取链接层数,如果获取到的url全部加入工作队列,将会是指数级增加,最后程序挂掉
if (deep < 3) {
SpiderUrl newUrl;
for (String u : urls) {
newUrl = new SpiderUrl(u,deep);
if(!workQueue.isExsit(newUrl)) {
workQueue.add(newUrl);
}
}
}
}
catch (IOException e) {
e.printStackTrace();
}
}
/**
* 读取http url 内容
* @param connection
* @return
* @return String
*/
private String getResource(URLConnection connection) {
if (connection == null) {
return null;
}
StringBuilder sb = new StringBuilder();
try {
InputStream inputStream = connection.getInputStream();
InputStreamReader isr = new InputStreamReader(inputStream, "UTF-8");
int input;
while ( (input = isr.read()) != -1) {
sb.append((char)input);
}
}
catch (IOException e) {
System.out.println(threadName + ",get resource error,connection=" + connection);
}
return sb.toString();
}
/**
* 从url内容获取标题
* @param content
* @return
* @return String
*/
private String getTitle(String content) {
if (content == null) {
return null;
}
Pattern pattern = Pattern.compile("(<title>.{1,}</title>)");
Matcher matcher = pattern.matcher(content);
String title = null;
if (matcher.find()) {
title = matcher.group(0).replaceAll("<title>", "").replaceAll("</title>", "");
}
return title;
}
/**
* 从url内容中获取存在的url链接
* @param content
* @return
* @return List<String>
*/
private List<String> getUrls(String content) {
if (content == null) {
return null;
}
Pattern pattern = Pattern.compile("(<a.{1,}?href=[‘\"]?[a-zA-z]+:\\/\\/[^\\s]*?[\\s>]{1})");
Matcher matcher = pattern.matcher(content);
String a;
String lastChar;
List<String> links = new ArrayList<String>();
while (matcher.find()) {
a = matcher.group(0).replaceAll("<a.{1,}?href=[‘\"]?", "");
a = a.trim();
lastChar = a.substring(a.length()-1);
if (lastChar.equals("‘") || lastChar.equals("\"") || lastChar.equals(">")) {
a = a.substring(0,a.length()-1);
}
links.add(a);
}
return links;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
该代码示例,旨在说明一个简单的爬虫,关于多线程和http的处理没有过多考虑,如存在错误,请指出。
以上是关于[网络]应用层协议:HTTP / HTTPS[转载]的主要内容,如果未能解决你的问题,请参考以下文章
转载 : Android webview在https下实现ssl的双向认证