관리 메뉴

A seeker after truth

231024 화 Day6 - 크롤링2: http, 브라우저 본문

Data/데엔 데브코스 TIL

231024 화 Day6 - 크롤링2: http, 브라우저

dr.meteor 2023. 10. 24. 11:04

1. HTTP

이미지, 동영상, 오디오, 텍스트를 포함한 Hypertext 즉, Hyperlink와 같은 링크 기반의 데이터를 주고 받기 위한 프로토콜이다. FTP, 텔넷 등이 들어있는 OSI Layer 7(응용 계층)에 속해있다.

 

웹 브라우저에서 HTTP request의 head, method, path 등을 볼 수 있는 이유? 브라우저란 게 알고 보면  http 요청, 응답 송수신을 도와주는 하나의 프로그램이라 그렇다. 그래서 코드 없이 이 모든 동작이 가능한 것. 그 기능 일부를 파이썬으로 구현해볼 수 있으며, 이 때 사용되는 라이브러리가 urllib3, requests 인 것.

 

 

2. HTML

웹 브라우저마다 지원하는 태그와 속성이 다르다. 그 비교표도 있음.

웹 스크래핑 관점에서 html을 정리하면, 우리가 원하는 내용이 html 문서의 어디에 있지? 어떤 태그로 묶여 있지?를 관찰해야 한다.

 

 

3. 윤리적 스크래핑, 크롤링

1) 고려할 것

웹 스크래핑: 특정 목적으로 특정 웹 페이지에서 데이터를 추출하는 것   ex) 날씨/주식 데이터 갖고 오기

vs

웹 크롤링: URL을 타고 다니며 반복적으로 데이터를 갖고 오는 과정 (데이터 색인) ex) 검색 엔진의 웹 크롤러

 

올바르게 http 요청을 보내려면, 위 두 기술로 어떤 목적을 달성하고자 하며 이러한 스크래핑, 크롤링이 서버에 어떤 영향을 미치는지 봐야 한다. 특히 상업적으로 사용할 때. 또 크롤링/스크래핑 도중에 서버에서 access를 거부당하지 않으려면, HTTP Header를 약간 바꿔야한다.

 

디도스 = 서버에 무차별적 요청 보내서 다운 시키는 건데, 크롤링 하면 사실상 이거랑 다름 없는... 일이 될지도 모름

requests를 통해 받은 변수 res에서 .text와 .content의 차이:  requests.get을 통해 받은 객체의 .text는 파싱되지 않았지만 .encoding을 통해 디코드 된 HTMl코드를 의미한다. 반면 .content는 아직 .encoding을 통해 디코드 되지 않은 상대적으로 날것의 정보를 의미한다. 따라서 이 둘을 출력해보면 .text의 경우 html코드로 출력되지만, .content의 경우 해석하기가 난해하다.

 

 

2) 로봇

로봇 배제 프로토콜(REP): 로봇(저렇게 무차별적으로 크롤링 하는 게 진짜 봇이 아니더라도 봇이랑 똑같잖아 하는 짓이. 걍 퉁쳐서 봇인거)을 이 브라우징 과정에서 어떻게 배제할 것인가? 에 대한 규약이다.

크롤러들은 위 규약을 지키면서 크롤링한다. 이 키워드는 모든 user-agent에 대해 접근을 거부한다는 뜻이다.

 

user-agent: *(=와일드카드에서의 별. 즉 '모두')를 대표하는 프로그램. 즉 "누가 이 유저 요청 보냈어?"라는 뜻 (뭔말인지 모르겠음). 즉 모든 유저에 대해 '/', 즉 맨 처음부터, 앞부터 모든 정보를 다 거부할거야. 란 뜻.

반면 disallow 가 그냥 allow 가 되면 모든 유저에 대해 접근 허용한다는 뜻. 또 유저 에이전트에 특정 에이전트를 명시할 수도 있음(ex: Mussgbot - 특정 user-agent에 대해 접근을 불허한다는 뜻)

 

네이버의 robots.txt 확인해보면 위 같이 나오는데 해석하면, 모든 들어오는 기기 요청에 대해 접근(크롤링) 불허. 허락하는 건 오직 /$ 이게 무슨 말이냐면 "www.naver.com/" <-여기 붙어있는 / 이하 뭐 music, news, ...  만 허용하겠다는 뜻임. 개발자들이 이런 규약 작성해줬을 것이다.

 

모든 유저들에 대해 저것들은 다 비허용. 그 외 것은 허용하겠다.

 

 

4. DOM

브라우저가 html 등의 문서를 어떻게 그렇게 예쁘게 만들 수 있는 걸까? 그 과정 첫 단계가 브라우저 속 "렌더링 엔진"이다. 왜 브라우저는 굳이 돔을 만들어내는 걸까?

 

돔의 핵심은 각 노드 안 요소를 객체처럼 간주하겠단 뜻이고, 이럼 뭐가 좋느냐?하면 어떤 성질, 액션이 있는 자료...로 치면 일과 객체의 성질을 우리가 활용할 수 있으며 곧 body.div 이런 식으로 접근할 수 있게 된단 뜻이다 아하~~~!!

이러면 html 태그 안에 헤더와 바디가 있다 어쩌고 와  같은 식으로...

 

그럼 브라우저는 이를 어떻게 다루는가? 우선 돔을 형성한 뒤, dom manipulation 즉 돔 조작을 할 수 있. html을 조작한다는 말인데, 현대의 동적 웹사이트(자스 파일이 브라우저 안에 내장되어 돔의 필드, 속성 등을 조작하거나 특정 원소 추가할 수 있는) 같은 거.

ex) var imgElement = document.createElement("img"); document.body.appendChild(imgElement);

 

또 돔 트리 순회해 특정 원소를 찾을 수도.

ex) document.getElementsByTagName("h2")

요게 스크래링에 활용되는 아이디어. 웹 브라우저를 돔으로 파싱해두면 나중에 쓰기 편하더라 하는. 이걸 갖고 오고자 하는 거다. 이걸 파싱해서 이후에 다루면 어떻게 될까 하는 것

 

크롤러는 결국 브라우저를 대신하는 프로그램을 만드는 거나 마찬가지며, 그래서 요청응답 보내는 것 말고도 html 파서가 포함되는 거다!

 

 

 

'Data > 데엔 데브코스 TIL' 카테고리의 다른 글

231026 목 Day8 - 크롤링4: 셀레늄  (0) 2023.10.26
231025 수 Day7 - 크롤링3: BeautifulSoup  (0) 2023.10.25
231023 월 Day5 - 크롤링1: html css  (0) 2023.10.23
231019 목 Day4  (0) 2023.10.19
231018 수 Day3  (0) 2023.10.18