http 프로토콜은 인터넷에서 가장 중요하고 기본적인 프로토콜 중 하나입니다. 크롤러는 종종 http 프로토콜을 처리해야 합니다. 다음 기사에서는 python 크롤러를 시작하고 HTTP 프로토콜을 빠르게 이해하는 데 대한 관련 정보를 주로 소개합니다. 기사의 소개는 필요한 친구가 참조할 수 있습니다. 함께 살펴보세요.
Preface
크롤러의 기본 원리는 HTTP 요청을 만들기 위해 브라우저를 시뮬레이션하는 것입니다. 크롤러 작성에 필요한 기초, 채용 웹사이트의 크롤러 위치에는 HTTP 프로토콜 사양에 능숙하다는 것도 명시되어 있습니다. 크롤러를 작성할 때는
부터 시작해야 합니다. HTTP 프로토콜이 무엇인가요?
귀하가 탐색하는 모든 웹페이지는 HTTP 프로토콜을 기반으로 제공됩니다. HTTP 프로토콜은 인터넷 애플리케이션에서 클라이언트(브라우저)와 서버 간의 데이터 통신을 위한 프로토콜입니다. 프로토콜은 클라이언트가 서버에 요청을 보내야 하는 형식과 서버가 반환하는 응답 형식을 규정합니다.
모든 사람이 프로토콜에 따라 요청을 시작하고 응답 결과를 반환하는 한 누구나 HTTP 프로토콜을 기반으로 자신의 웹 클라이언트(브라우저, 크롤러) 및 웹 서버(Nginx, Apache 등)를 구현할 수 있습니다. .
HTTP 프로토콜 자체는 매우 간단합니다. 클라이언트는 요청을 적극적으로 시작할 수만 있고 서버는 요청을 수신하고 처리한 후 응답 결과를 반환한다고 규정합니다. 동시에 HTTP는 state이 없는 프로토콜이며 프로토콜 자체는 그렇지 않습니다. 클라이언트의 요청 내역 기록을 기록합니다.
@HTTP 프로토콜은 요청 형식과 응답 형식을 어떻게 규정합니까? 즉, 클라이언트는 어떤 형식으로 HTTP 요청을 올바르게 시작할 수 있습니까? 클라이언트가 올바르게 구문 분석할 수 있도록 서버는 응답 결과를 어떤 형식으로 반환합니까?
HTTP request
@HTTP 요청은 세 개의 groups, 즉 요청 라인, 요청 헤더 및 요청 본문으로 구성됩니다. , 헤더와 요청 본문은 선택 사항이며 모든 요청에 필수는 아닙니다.
요청 라인
요청 라인은 모든 요청의 필수 부분이며 3개로 구성됩니다. 이는 request method(메서드), 요청 URL(URI), HTTP 프로토콜 버전 등의 부분으로 구성되며 공백으로 구분됩니다.
HTTP 프로토콜에서 가장 일반적으로 사용되는 요청 방법은 GET, POST, PUT, DELETE입니다. GET 방식은 서버에서 리소스를 얻는 데 사용되며, 크롤러의 90%는 GET 요청을 기반으로 데이터를 크롤링합니다.
요청 URL은 리소스가 위치한 서버의 경로 주소를 나타냅니다. 예를 들어 위의 예에서는 클라이언트가 리소스 index.html을 얻으려고 하며 해당 경로는 루트 디렉터리 아래에 있음을 나타냅니다. (/) 서버 foofish.net.
요청 헤더
@요청 라인을 통해 전달되는 정보의 양이 매우 제한되어 있기 때문에 클라이언트는 여전히 클라이언트에게 할 말이 많습니다. 서버 사물은 요청 헤더(헤더)에 배치되어야 합니다. 요청 헤더는 서버에 몇 가지 추가 정보를 제공하는 데 사용됩니다. 예를 들어 User-Agent는 클라이언트의 신원을 나타내고 서버에 이를 알리는 데 사용됩니다. 요청은 브라우저나 크롤러 또는 Chrome에서 발생합니다. 브라우저는 여전히 FireFox입니다. HTTP/1.1은 47개의 헤더 필드 유형을 지정합니다. HTTP 헤더 필드의 형식은 콜론으로 구분된 키-값 쌍으로 구성된 Python의 사전 유형과 매우 유사합니다. 예:
User-Agent: Mozilla/5.0
클라이언트가 요청을 보낼 때 전송되는 데이터(메시지)는 요청 헤더의 끝과 요청 본문의 시작을 구별하기 위해 공백으로 구성됩니다. line을 사용하여 빈 줄에 도달하면 헤더의 끝이자 요청 본문의 시작임을 의미합니다.
요청 본문
@요청 본문은 클라이언트가 서버에 제출한 실제 콘텐츠입니다(예: 요청 시 필요한 사용자 이름 및 비밀번호). 사용자가 로그인합니다. 예를 들어, 사용자 정보 등록 시 제출한 양식 정보 등의 파일 업로드 데이터입니다.
이제 Python에서 제공하는 원래 API 소켓 모듈을 사용하여 서버에 대한 HTTP 요청을 시뮬레이션합니다
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: # 1. 与服务器建立连接 s.connect(("www.seriot.ch", 80)) # 2. 构建请求行,请求资源是 index.php request_line = b"GET /index.php HTTP/1.1" # 3. 构建请求首部,指定主机名 headers = b"Host: seriot.ch" # 4. 用空行标记请求首部的结束位置 blank_line = b"\r\n" # 请求行、首部、空行这3部分内容用换行符分隔,组成一个请求报文字符串 # 发送给服务器 message = b"\r\n".join([request_line, headers, blank_line]) s.send(message) # 服务器返回的响应内容稍后进行分析 response = s.recv(1024) print(response)
HTTP 응답
서버는 요청을 수신하고 처리한 후 응답 콘텐츠를 클라이언트에 반환합니다. 마찬가지로 브라우저가 응답 콘텐츠를 올바르게 구문 분석하려면 응답 콘텐츠가 고정된 형식을 따라야 합니다. HTTP 응답도 HTTP 요청 형식에 해당하는 응답 줄, 응답 헤더, 응답 본문의 세 부분으로 구성됩니다.
响应行
响应行同样也是3部分组成,由服务端支持的 HTTP 协议版本号、状态码、以及对状态码的简短原因描述组成。
状态码是响应行中很重要的一个字段。通过状态码,客户端可以知道服务器是否正常处理的请求。如果状态码是200,说明客户端的请求处理成功,如果是500,说明服务器处理请求的时候出现了异常。404 表示请求的资源在服务器找不到。除此之外,HTTP 协议还很定义了很多其他的状态码,不过它不是本文的讨论范围。
响应首部
响应首部和请求首部类似,用于对响应内容的补充,在首部里面可以告知客户端响应体的数据类型是什么?响应内容返回的时间是什么时候,响应体是否压缩了,响应体最后一次修改的时间。
响应体
响应体(body)是服务器返回的真正内容,它可以是一个HTML页面,或者是一张图片、一段视频等等。
我们继续沿用前面那个例子来看看服务器返回的响应结果是什么?因为我只接收了前1024个字节,所以有一部分响应内容是看不到的。
b'HTTP/1.1 200 OK\r\n Date: Tue, 04 Apr 2017 16:22:35 GMT\r\n Server: Apache\r\n Expires: Thu, 19 Nov 1981 08:52:00 GMT\r\n Set-Cookie: PHPSESSID=66bea0a1f7cb572584745f9ce6984b7e; path=/\r\n Transfer-Encoding: chunked\r\n Content-Type: text/html; charset=UTF-8\r\n\r\n118d\r\n <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">\n\n <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\n <head>\n\t <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1" /> \n\t <meta http-equiv="content-language" content="en" />\n\t ... </html>
从结果来看,它与协议中规范的格式是一样的,第一行是响应行,状态码是200,表明请求成功。第二部分是响应首部信息,由多个首部组成,有服务器返回响应的时间,Cookie信息等等。第三部分就是真正的响应体 HTML 文本。
至此,你应该对 HTTP 协议有一个总体的认识了,爬虫的行为本质上就是模拟浏览器发送HTTP请求,所以要想在爬虫领域深耕细作,理解 HTTP 协议是必须的。
【相关推荐】
1. python爬虫入门(4)--详解HTML文本的解析库BeautifulSoup
2. python爬虫入门(3)--利用requests构建知乎API
3. python爬虫入门(2)--HTTP库requests
위 내용은 Python 크롤러 시작하기(1) - HTTP 프로토콜을 빠르게 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!