크롤링
예전에는 각 웹 페이지가 있으면 사용자가 그 웹 페이지에 접근하기 위해서는 각 페이지의 도메인을 다 알고 있어야 했다. 그래서 내가 원하는 정보가 어떤 페이지에 있는지 미리 알고 그 페이지의 도메인으로 접근해야 하는 것이다.
크롤링은 검색을 위해서 만들어졌다고 봐도 된다. 구글에서 검색을 하면 검색어에 해당하는 글들을 홈페이지에서 알아서 서버로 가져와 준다. 이렇게 크롤링(WWW 을 자동화해서 탐색)을 수행하는 아이를 크롤러라고 하고, 구글의 검색 엔진을 크롤러 봇이라고 한다.
웹 크롤러(web crawler)는 조직적, 자동화된 방법으로 월드 와이드 웹을 탐색하는 컴퓨터 프로그램이다. 크롤링은 WWW을 본따는 것이라면 파싱은 조금 더 좁은 범위로 원하는 정보만을 가져오는 것을 말한다.
WWW
개발자 도구로 네이버 페이지를 띄워보면 아래와 같이 나온다. Request header는 우리가 어떤 것을 요청했는지 보여준다. accept는 사용자가 이 페이지를 XML로 읽기를 원하는지 HTML로 읽기를 원하는지를 정해준다. cookie는 홈페이지에 로그인하면 암호화된 정보가 들어가서 cookie를 알고 있으면 다른 사람이 내 아이디로 로그인이 가능하니 조심해야 한다. referer는 웹이 어디서 왔는지, sec 들은 보안에 관련된 정보들을 정해준다. user agent는 사용자가 어떤 브라우저를 통해서 어떠한 기기를 통해서 접근했는지를 알려주어, 해외에서 접근할 떄 경고를 띄워줄 수 있다.
이렇게 홈페이지에 요청을 보내면 Response header에 정보를 실어 보내준다. Response header는 metadata이기 때문에 실제 데이터는 보여주지는 않지만 content-type에서 어떤 타입으로 정보를 줄것인지 인코딩은 뭘로 할것인지를 정해준다.
각 페이지는 document라고 하고, reponse에서는 실제 원본 데이터를 보여준다.
웹서버와 디비
홈페이지에서 보여지는 모들 것들은 데이터베이스에 들어있고, 데이터베이스는 또 하나의 웹서버 처럼 동작한다. 데이터베이스는 쉽게 말하면 테이블(표)이다. 웹 서버는 사용자의 요청을 받으면 데이터베이스에서 요청에 맞는 데이터를 꺼내서 사용자에게 보여줄 것이다. 웹 서버는 데이터베이스에서 꺼낸 데이터를 그대로 사용자에게 주지는 않고 별도의 logic으로 정제를 해서 준다. 예를 들어 사용자가 어떤 뉴스를 클릭했을 때 logic에 추천시스템을 넣어서 클릭한 뉴스와 비슷한 뉴스를 같이 보내줄 수도 있다.
HTTP와 소켓
HTTP는 사용자가 웹서버와 통신할 때 어떠한 통신 규격을 사용할 것인지를 말한다. HTTP를 뜯어보면 아래와 같이 문자열이고, HTTP라는 문자열을 서버로 주는 것이다. 스페이스와 줄바꿈으로 나뉘어지는 규칙을 HTTP라고 생각하면 쉽다.
GET /index.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.naver.com
Accept-Language: ko-kr
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
이 문자열을 보내면 웹 서버는 아래와 같은 응답을 준다.
HTTP/1.1 200 OK
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.naver.com
Accept-Language: ko-kr
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Content-Length: 1000
<html>hello</html>
HTTP의 규칙을 좀 더 정리해보면 request line이라는 것이 첫 줄에 존재하고, 0개 이상의 헤더, 빈 라인, 바디로 이루어진다. SP는 스페이스이고, CRLF는 한줄 내리고 왼쪽으로 미는 것(줄바꿈)이다.
헤더는 :으로 구분되어지는 key: vlaue 값이고 여러개의 값이 있는 경우는 ;로 구분한다. 바디는 본문이나 데이터라고 생각하면 된다. Content-Type은 바디의 타입을 지정해주고, Content-Length는 바디의 최대 길이를 제한한다.
POST /upload HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.naver.com
Accept-Language: ko-kr
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Content-Length: 1000
Image body image body image body
HTTP method는 다음과 같다.
- GET: 데이터를 주지 않고 받기만 함
- HEAD: 헤더만 가지고 올 때 사용
- POST: 데이터를 주고 그에 맞게 응답값을 받음 ex) SNS에 글 올리기
- PUT: 데이터를 수정하는 용도 ex) SNS 글을 수정
- DELETE: 데이터를 삭제
- OPTIONS
HTTP status code 정리
- 100-199 정보전달용
- 200-299 성공
- 300-399 리다이렉트(바로가기 연결)
- 400-499 클라이언트 에러(request 에러 - 빈 문자열의 댓글 다는 경우)
- 500-599 서버 에러(response 에러 - 데이터베이스에 문제가 있는 경우)
아래는 특정 사이트에 로그인해서 계좌에 돈이 얼마있는지 확인하는 코드이다. 처음에 클라이인트가 바디에 아이디와 패스워드를 넣어서 보내면 (form data, json 등의 형식으로) 웹 서버는 set-cookie로 해당 아이디를 임시로 보관한다. 쿠키에는 아이디 비밀번호 정보가 담겨있다고 보면 된다. 다시 클라이언트는 쿠기값을 보내서 로그인하면 계좌에 들어있는 잔액을 보여주는 형식이다. HTTP는 암호화를 하지 않지만, HTTPS 는 아이디나 비밀번호 같은 것들을 암호화 해서 보낸다.
HTTP는 request와 response가 항상 짝을 이뤄서 응답을 한다. response가 없는 request는 실패한 요청이라고 보면 된다. 반면에 웹 소켓은 몇 번이고 response가 없어도 계속 request를 날릴 수 있고, 한번의 request를 날려도 여러번의 response가 올수도 있다.
브라우저
웹 서버는 HTTP를 문자열 그대로 흰색 바탕에 까만 글씨로 보내게 된다.
브라우저는 UI를 렌더링한다고 하는데 HTML 파일을 실제로 우리가 보는 예쁜 화면으로 만들어 준다.
브라우저는 북마크나 예전에 접속했던 페이지들을 보여주기도 한다. 또한, 브라우저는 보안적으로 강한 규율을 정해준다. 사이트에 접속할 때 쿠키를 허용하시겠습니까? 이런것도 관리해준다. 그리고 브라우저는 스크립트(자바 스크립트)를 실행해주어 동적인 페이지를 만들 수 있다.
웹앱과 API
웹앱은 웹이 하나의 프로그램처럼 다양한 기능과 다양한 역할을 수행하는 것이다. 그리고 웹앱이 그렇게 작동하기 위해서 Rest API 라는 것을 사용하게 된다.
웹앱의 특징은 UI과 그 안에 들어가는 데이터베이스를 분리해놓는다는 것이다. 항상 로딩되어 있는 부분과 첫 로딩때부터 불러오지 않는 부분이 있는 것이 그 이유이다.
크롤링은 UI를 파싱하는것이 아니라 서버와 데이터를 주고 받는 부분을 따라하는 것이다. 그것을 통틀어서 API라고 한다. 위의 그림을 다시 보면 우리가 처음에 페이지에 접속하면 골격만 로딩하고 내용은 채우지 않는다. 골격을 로딩한 후에 내용을 다시 서버에 요청하는데 이 역할을 하는 것이 API이다. 여러 사람이 하나의 HTML 파일을 다루다 보니 충돌이 나서 부분적으로 따로 HTML을 작성하면서 이렇게 발전했다.
정적 크롤링 vs 동적 크롤링
정적 크롤링은 한 페이지 안에서 원하는 정보가 모두 드러나는 경우에 데이터를 수집하는 것이라면, 동적 크롤링은 유저가 하는 행위를 예를 들어 입력, 클릭, 로그인 같은 동작을 따라하면서 페이지 이동이 있어야 보이는 데이터를 수집하는 것이다.
