[크롤링/04] HTTP 기본 총 정리

정의

HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다.

 

위키 백과

HTTP - 위키백과, 우리 모두의 백과사전

개발자를 위한 웹 기술 한국어 번역(Mozilla)

HTTP 요청 메서드 - HTTP | MDN

---

메시지 포맷 요약 표 & REST API

HTTP 메소드	RFC	요청에 Body가 있음	응답에 Body가 있음	안전	Idempotent	캐시 가능
GET	RFC 7231	아니오	예	예	예	예
HEAD	RFC 7231	아니오	아니오	예	예	예
POST	RFC 7231	예	예	아니오	아니오	예
PUT	RFC 7231	예	예	아니오	예	아니오
DELETE	RFC 7231	아니오	예	아니오	예	아니오
CONNECT	RFC 7231	예	예	아니오	아니오	아니오
OPTIONS	RFC 7231	선택 사항	예	예	예	아니오
TRACE	RFC 7231	아니오	예	예	예	아니오
PATCH	RFC 5789	예	예	아니오	아니오	예

 

웹 애플리케이션의 처리는 대부분 GET, POST, PUT, DELETE로 이루어진다.

이 메서드들은 URL이 나타내는 리소스에 다음과 같은 CRUD 처리를 하겠다고 나타낸다.

• POST: 리소스 만들기(CREATE)
• GET: 리소스 참조하기(READ)
• PUT: 리소스 변경하기(UPDATE)
• DELETE: 리소스 제거하기(DELETE)

이처럼 URL이 나타내는 리소스에 취할 행동을 HTTP 메서드(CRUD)로 나타내는 설계를 'REST 아키텍처'라고 부른다.

 

환경에 따라 GET과 POST 이외의 요청은 방화벽에 의해 막힐 수도 있다. 그래서 실제로는 GET과 POST 메서드만으로 구축된 웹 사이트가 굉장히 많은 상태다.

크롤러는 HTML 등의 리소스를 다운로드하는 것이므로 기본적으로 GET 메서드를 사용하지만, 다른 메서드를 사용해야 하는 경우도 존재한다.

요청 메서드의 사용 방법은 HTTP의 기본이지만, 실제 구축되어 있는 웹 사이트에서 이러한 기본을 지키지 않는 경우가 많으므로 주의해야 한다.

 

---

HTTP 응답 코드

1XX	Informational(정보)	정보 교환.
100	Continue	클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내주길 바람. (HTTP 1.1에서 처음 등장)
101	Switching Protocols	서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임. (HTTP 1.1에서 처음 등장)
2XX	Success(성공)	데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음.
200	OK	오류 없이 전송 성공.
202	Accepted	서버가 클라이언트의 요청을 수락함.
203	Non-authoritavive Information	서버가 클라이언트 요구중 일부만 전송.
204	Non Content	클라이언트의 요구를 처리했으나 전송할 데이터가 없음.
205	Reset Content	새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 함. (브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용됨.) (HTTP 1.1에서 처음 등장)
206	Partial Content	클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음. (HTTP 1.1에서 처음 등장)
3XX	Redirection(방향 바꿈)	자료의 위치가 바뀌었음.
300	Multiple Choices	최근에 옮겨진 데이터를 요청.
301	Moved Permanently	요구한 데이터를 변경된 URL에서 찾았음.
302	Moved Permanently	요구한 데이터가 변경된 URL에 있음을 명시. 301과 비슷하지만 새 URL은 임시 저장 장소로 해석됨. [8]
303	See Other	요구한 데이터를 변경하지 않았기 때문에 문제가 있음.
304	Not modified	클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨 (보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우).[9]
305	Use Proxy	요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함. (HTTP 1.1에서 처음 등장)
307	Temporary Redirect	자료가 임시적으로 옮겨짐.
4XX	Client Error(클라이언트 오류)	클라이언트 측의 오류. 주소를 잘못 입력하였거나 요청이 잘못 되었음.
400	Bad Request	요청 실패. 문법상 오류가 있어서 서버가 요청사항을 이해하지 못함,[10]
401.1	Unauthorized	권한 없음 (접속실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지 않음.[11]
401.2	Unauthorized	권한 없음 (서버설정으로 인한 접속 실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지않음.[12]
401.3	Unauthorized	권한 없음 (자원에 대한 ACL에 기인한 권한 없음). 클라이언트가 특정 자료에 접근할 수 없음.[13]
401.4	Unauthorized	권한 없음 (필터에 의한 권한 부여 실패). 서버에 접속하는 사용자들을 확인하기 위해 설치한 필터 프로그램이 있음.[14]
401.5	Unauthorized	권한 없음 (ISA PI/CGI 애플리케이션에 의한 권한부여 실패). 이용하려는 서버의 주소에 ISA PI나 CGI프로그램이 설치되어 있고, 권한을 부여할 수 없음.[15]
402	Payment Required	예약됨.
403.1	Forbidden	금지 (수행접근 금지). 수행시키지 못하도록 되어있는 디렉터리 내의 실행 파일을 수행하려고 하였음.
403.2	Forbidden	금지 (읽기 접근 금지). 접근한 디렉터리에 가용한 기본 페이지가 없음.[16]
403.4	Forbidden	금지 (SSL 필요함). 접근하려는 페이지가 SSL로 보안유지 되고 있음.[17]
403.5	Forbidden	금지 (SSL 128필요함). 페이지가 128비트의 SSL로 보안유지 되고 있음.[18]
403.6	Forbidden	금지 (IP 주소 거부됨). 사용자가 허용되지 않은 IP로부터 접근함.
403.7	Forbidden	금지 (클라이언트 확인 필요). 클라이언트가 자료에 접근할 수 있는지 확인 요함.[19]
403.8	Forbidden	금지 (사이트 접근 거부됨). 서버가 요청사항을 수행하고 있지 않거나, 해당 사이트에 접근하는 것이 허락되지 않음.
403.9	Forbidden	접근금지 (연결된 사용자수 과다). 서버가 BUSY 상태에 있어서 요청을 수행할 수 없음.
403.10	Forbidden	접근금지 (설정이 확실 하지 않음).
403.11	Forbidden	접근금지 (패스워드 변경됨). 잘못된 암호를 입력했음.
403.12	Forbidden	접근금지(Mapper 접근 금지됨). 클라이언트 인증용 맵이 해당 웹 사이트에 접근하는 것이 거부됨.
404	Not Found	문서를 찾을 수 없음. 서버가 요 청한 파일이나 스크립트를 찾지 못함.
405	Method not allowed	메서드 허용 안됨. 요청 내용에 명시된 메서드를 수행하기 위해 해당 자원의 이용이 허용되지 않음.[20]
406	Not Acceptable	받아들일 수 없음.[21]
407	Proxy Authentication Required	프록시 서버의 인증이 필요함.[22]
408	Request timeout	요청 시간이 지남.
409	Conflict	요청을 처리하는 데 문제가 있음. 보통 PUT 요청과 관계가 있다. 보통 다른 버전의 파일을 업로드할 경우 발생함. (HTTP 1.1에서 새로 등장)
410	Gone	영구적으로 사용할 수 없음.
411	Length Required	클라이언트가 헤더에 Content-Length를 포함하지 않으면 서버가 처리할 수 없음.(HTTP 1.1에서 새로 등장)
412	Precondition Failed	선결조건 실패. 헤더에 하나 이상의 선결조건을 서버에서 충족시킬 수 없음.[23]
413	Request entity too large	요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼.[24] (HTTP 1.1에서 새로 등장)
414	Request-URI too long	요청한 URI가 너무 김.[25]
415	Unsupported media type	요청이 알려지지 않은 형태임. (HTTP 1.1에서 새로 등장)
5XX	Server Error(서버 오류)	서버 측의 오류로 올바른 요청을 처리할 수 없음.
500	Internal Server Error	서버 내부 오류.[26]
501	Not Implemented	필요한 기능이 서버에 설치되지 않았음.[27]
502	Bad gateway	게이트웨이 상태 나쁨.[28]
503	Service Unavailable	외부 서비스가 죽었거나 현재 멈춘 상태 또는 이용할 수 없는 서비스.[29]
504	Gateway timeout	프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있음. 초기 서버가 원격 서버로부터 응답을 받을 수 없음. (HTTP 1.1에서 새로 등장)
505	HTTP Version Not Supported	해당 HTTP 버전을 지원하지 않음.

 

상태 코드 별 크롤러 대응 방법

• 2xx 또는 3xx 처럼 일반적인 상태 코드를 응답했다면 처리를 진행
• 404처럼 콘텐츠가 존재하지 않는 경우, 예외 목록에 추가하는 등의 처리를 해서 다음 회에 크롤링하지 않게 만든다.
• 5xx 등의 서버 오류가 발생한 경우, 처리를 중지한다.

예외는 catch 해서(try-except) 상태 코드를 확인할 수 있다. 오류 응답을 받았을 때 이를 어떻게 처리하는지는 라이브러리에 따라 다르다. 그리고 라이브러리에 따라 그러한 처리 방법을 변경할 수 있는 경우도 많다. 따라서 상태 코드에 따라 처리를 분기해야 하는 경우 라이브러리의 처리 방법을 잘 확인해서 사용해야 한다.

 

HTTP 응답을 믿을 수 없는 경우

• 오류가 발생했는데도 200을 응답하는 경우
  • 상태 코드만으로 크롤링 지속 여부 판단 불가
  • 응답 상태 코드가 아니라 응답된 HTML의 내용을 확인해서 처리해야 함
  • 정상적인 응답을 하는 경우에도 HTML 내부에 "오류 발생가 발생했습니다" 또는 "이 페이지는 존재하지 않습니다" 같은 메시지가 있을 수도 있음
• 페이지가 존재하지 않는 경우의 리다이렉트
  • 리다이렉트해서 이동한 페이지의 HTML 내용을 확인
  • 리다이렉트와 다르게 URL이 변경된 경우에는 canonical 확인
• 서버에 접속할 수 없는 경우
  • 일시적인 네트워크 문제 서버 장애 또는 유지 보수 등 서버가 다운된 경우
    • 일정 시간 대기 후 재 시도
  • 장기간 지속될 경우에는 웹 사이트 자체 폐쇄 또는 도메인 이전 의심

 

대처 방법

1. 400 Bad Request: 요청 매개 변수가 불충분한 경우처럼 요청 내용에 문제가 있다는 것 → 요청 내용 수정 필요
2. 401 Unauthorized: 대상 리소스에 대한 인증이 필요 ➡ 접근 제한有
3. 403 Forbidden: 조회 금지 → 크롤링 거부 의사를 밝힌 것 ➡ 크롤링 중단(만약 어느 정도 시간이 지난 뒤 다시 요청이 가능해지는 사이트라면 요청 간격을 조금 더 늘리는 등의 대처 필요)
4. 404 Not Found: 대상 리소스가 존재X 또는 대상 리소스에 접근할 권한X ➡ 해당 요청에 응답할 것이 X(ex. GET 메서드에는 200 OK, HEAD 메서드에는 404 Not Found를 응답하는 경우)
5. 405 Method Not ALlowed: 해당 메서드로의 접근이 허가되지 않을 경우(정적인 HTML 파일, CSS 파일, 이미지 파일 등에 POST 메서드로 요청을 걸면 이러한 상태 코드가 응답)
6. 406 Not Acceptable: 서버가 클라이언트로부터 받은 Accept 계열의 헤더 요구를 충족할 수 없는 경우
7. 408 Request Timeout: 클라이언트와 서버 사이의 통신 시간이 서버에서 설정한 타임아웃 시간을 넘는 경우 ➡서버가 많은 부하를 받는 상태일 가능성이 높음 ➡요청 시간 간격을 늘리는 등의 대처를 하는 것이 바람직
8. 500 Internal Server Error: 서버에서 어떤 오류가 발생한 경우 출력하는 상태 코드 ➡대상 서버에 어떤 문제가 발생했을 가능성이 높음 ➡즉각 크롤링 중지(다만, 일부 제대로 만들지 못한 웹 사이트에서 입력 양식 확인 오류 등이 발생했을 때 500 Internal Server Error가 응답되기도 함. 이러한 경우에는 요청 내용을 수정하면 정상적인 응답을 받을 수 있음)
9. 501 Not Implemented: 서버에서 해당 메서드를 지원하지 않는 경우 
10. 502 Bad Gateway: 게이트웨이 또는 프록시를 사용하는 서버가 상위 서버로부터 잘못된 응답을 받았을 경우 출력함. 프록시 서버의 설정이 잘못됐거나 중계 대상 서버가 다운됐을 경우에 일어남. 직접 관리하는 프록시 서버라면 설정을 고쳐 대처할 수 있지만, 웹 사이트에서 관리하는 프록시 서버라면 해당 서버의 담당자가 문제를 해겨할 때까지 기다리는 수밖에 없음
11. 503 Service Unavailbale: 서비스가 많은 부하를 받았거나 유지 보수 등의 이유로 잠시 사용할 수 없는 경우 ➡ 크롤링 중단 ➡ 웹 사이트를 지켜보다 정상적인 응답을 줄 때 다시 크롤링 시작(만약 웹 사이트가 반복해서 특정 시간마다 유지 보수를 한다면, 유지 보수 주기를 파악하고 유지 보수 시간을 피해서 크롤링)
12. 504 Gateway Timeout: 게이트웨이 또는 프록시로 동작하고 있는 서버가 상위 서버로부터 응답을 일정 시간동안 받지 못해서 타임아웃 된 경우 ➡ 사이트가 과부하로 응답을 못 하는 경우일 수 있으므로 크롤링 중지

 

 

 

 

---

HTTP 통신 내용 보기

Curl > 홈페이지

curl

curl --verbose <https://www.google.com>

—verbose 옵션을 붙이면 실제로 주고받는 요청과 응답의 내용을 확인할 수 있다.

비슷하게 크롬 개발자도구의 Network라는 탭을 보면 실제로 브라우저가 서버와 어떤 통신을 하는지 볼 수 있다.

 

---

 

일부 메서드가 지원되지 않는 경우

웹 사이트에 따라 HTTP에서 정의하는 메서드 중 일부를 지원하지 않는 경우가 있다. 그중에서도 HEAD 메서드를 지원하지 않는 경우가 특히 불편하다.

HEAD 메서드는 응답 바디를 응답하지 않기때문에, 변경되었을 가능성이 낮은 콘텐츠의 경우 일단 HEAD 메서드를 사용해 Last_Modified 헤더를 확인하고 이 값이 변경된 경우에만 GET 메서드를 사용해 다운로드하게 구현하면 통신량을 크게 줄일 수 있다.

 

서버로부터 응답받은 상태 코드가 원래의 의미를 나타내는지(해당 메서드가 지원되지 않아 리턴받지 못하는 경우 등) 확인하기 힘든 경우도 있다. 이러한 경우에는 CURL 명령어 등으로 요청을 보내 보고 응답을 확인해 판단해야 한다.

 

---

 

메서드의 사용 방법이 적절하지 않은 경우

메서드는 지원되지만 해당 메서드가 원래의 의미로 사용되지 않는 경우도 있다.

 

1. GET이 아니라 POST 메서드로 화면을 이동하는 경우

 

일부 동적 웹사이트 → GET 메서드를 사용해야 하는 곳에 POST(원 목적: 데이터의 추가 처리를 위해 사용)메서드를 사용

• 화면 이동 시 필요한 매개 변수가 너무 많아서 쿼리 문자열로 이를 처리하기 힘든 경우
• 캐시를 강제로 막고 페이지에 접근할 때마다 새로운 콘텐츠를 출력하게 하고 싶을 때

첫번째 경우는 URL 또는 매개 변수 설계를 변경해서 회피할 수 있다.

두번째 경우는 응답 헤더 또는 meta 태그를 사용해 웹 브라우저의 캐시 여부를 제어할 수 있다.

 

2. GET 메서드로 데이터 변경 처리를 하는 경우

 

데이터 변경 처리처럼 원래 POST 메서드로 해야 하는 것을 GET 메서드를 사용해 처리하는 경우도 있다. 예를 들면 데이터 제거 처리가 아래처럼 HTML 링크로 구현된 경우가 대표적이다.

 

<a href="/delete/item/123">제거</a>

 

크롤러가 이러한 페이지를 순회하면 데이터가 모두 제거될 것이다. 그러니 크롤러를 만드는 경우 이러한 문제가 생길 수 있는지 반드시 확인해야 한다.

 

3. URL 인코드 방식의 차이에 따른 문제

 

GET 메서드로 매개 변수를 추가해 요청을 전송하는 경우, 요청 문자열이라고 부르는 매개 변수가 들어 있는 문자열을 URL 인코드해야 한다. 이러한 인코드 방식의 미묘한 차이로 인해 문제가 발생할 때가 있다.

 

• URL에 사용할 수 없는 문자(일반적으로 기호 또는 한국어 등)가 포함된 경우, 'URL 인코드'라고 부르는 일종의 이스케이프 처리를 해야 한다. URL 인코드는 문자를 바이트 단위로 변환하는 것이다. 일반적으로 %xx(xx부분은 16진수)로 변환하게 된다.
• URL 인코드는 문자열을 바이트 표현으로 변환한 것이므로 어떤 문자 코드로 인코드할지에 따라 달라진다. (한국어는 EUC-KR, UTF-8 등)
• 서버 쪽에서 이런 쿼리 문자열을 받으면 당연히 같은 문자 코드로 디코드해야 한다. 인코드 떄와 다른 문자 코드로 디코드하면 문자 깨짐이 발생한다.

---

 

* 참고

- EUC-KR : EUC-KR은 KS X 1001와 KS X 1003을 사용하는 8비트 문자 인코딩, EUC의 일종이며 대표적인 한글 완성형 인코딩이기 때문에 보통 완성형이라고 불린다.

- CP949 : 코드 페이지 949(CP949)는 마이크로소프트사가 도입한 코드 페이지이다. 본래는 KS C 5601의 완성형 한글을 표현한 코드 페이지였으나, 윈도 95부터는 확장 완성형 혹은 통합형 한글 코드(Unified Hangul Code)이라는 명칭으로 확장되어 현대의 모든 한글을 수용하게 되었다.

 

 

---

HTTP 헤더(mozilla)

HTTP 헤더 - HTTP | MDN

HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론 ':' 다음에 오는 값(줄 바꿈 없이)으로 이루어져있다. 값 앞에 붙은 빈 문자열은 무시된다.

 

General header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더

General header

Request header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

Request Header

Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더

Response Header

Entity header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더

 

Entity Header

---

크롤러의 사용자 에이전트

• 사용자 에이전트(User-Agent 헤더)는 접근 중인 웹 브라우저의 종류와 버전 등을 나타내는 헤더
• 프로그램에서 HTTP 요청을 보낼 때 사용하고 있는 HTTP 클라이언트 라이브러리의 버전을 나타내는 사용자 에이전트가 디폴트로 설정되는 경우가 많음
• 크롤러를 운용할 때는 크롤링 대상 웹 사이트 소유자에게 '어떤 사업자가 어떤 서비스를 위해 운영하는 크롤러인가'를 알려줄 수 있게 사용자 에이전트를 설정하는 것이 좋음

구글 크롤러 에이전트 설명> developers.google.com/search/docs/advanced/crawling/overview-google-crawlers

 

Google 크롤러(사용자 에이전트) 개요  |  Google 검색 센터  |  Google Developers

Top 10 Web Crawlers/ User Agents(Google, Yahoo, Bing 등의 모범 사례)> www.keycdn.com/blog/web-crawlers

Web Crawlers and User Agents - Top 10 Most Popular - KeyCDN

User Agent Wiki

사용자 에이전트 - 위키백과, 우리 모두의 백과사전

User Agent Examples> developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent

User-Agent - HTTP | MDN

---

 

서버에서 크롤러 판별하는 방법

 

• 크롤러인지 판정할 수 있다면 일반 사용자의 응답에 영향을 주지 않게 크롤러로부터 받은 요청을 별도의 서버에서 처리하도록 하는 기능을 구현할 수 있음
• 서버에서 크롤러의 요청 여부를 판정할 때는 User-Agent 헤더를 사용하면됨
  • 크롤러의 사용자 에이전트는 굉장히 많아서 이를 하나하나 지정하는 것은 굉장히 힘듬
  • Woothee 라이브러리: 사용자 에이전트 파싱 라이브러리
• 사용자 에이전트가 설정되어 있지 않은 경우에는 일반적인 웹 브라우저의 사용자 에이전트로 위장해 요청하기도 함.
  • User-Agent 헤더 이외의 것(IP 주소, 요청 내용, 요청 패턴 등)을 사용해 판정해야 함

Woothee> github.com/woothee/woothee

woothee/woothee

Python, Java, Ruby, Perl, JS, PHP, Go, Rust, D 의 다양한 언어로 사용할 수 있다.

 

---

🍪쿠키가 필요한 웹 사이트

• HTTP: 상태 없는 프로토콜임
  • 각 요청과 응답이 모두 독립적 → 어떤 요청을 처리할 때 이전 요청의 정보를 활용할 수 없음
• 연속적인 요청에 대한 정보를 공유해야 하는 경우
  • 쿠키(Cookie): 웹 페이지 등에서 브라우저에 정보를 일시적으로 저장할 때 사용
  • 예시> 쿠키로 '세션 ID'라고 부르는 클라이언트 식별 전용 ID를 사용하고 이를 활용해 쇼핑 카트 기능 또는 인증 정보 등을 관리
• 그래서 어떻게 크롤링을 하면 되는가?

stackoverflow.com/questions/24114569/how-to-handle-cookies-in-a-crawler

How To handle cookies in a crawler

모든 문제를 한가지 방법으로 해결할 수는 없다. 하지만 쿠키에 대한 정보를 읽어올 수 있는 방법이 있으니, 쿠키의 목적 등 정보를 확인하고 그에 따라 해결을 하면 된다.

 

en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie

HTTP cookie - Wikipedia

---

국제화 지원되는 웹 사이트

• 지역/언어별로 다른 도메인/URL을 사용해 콘텐츠를 제공하는 경우: 각기 다른 웹 사이트로 취급
• 요청의 Accept-Language 헤더를 보고 콘텐츠를 제공하는 경우: 크롤링을 원하는 언어를 헤더로 지정

Accept-Language: ko
Accept-Language: ko, en
Accept-Language: ko, en-US;q=0.8, en;q=0.6, ja;q=0.4

• 접근한 IP 주소를 기반으로 사용자의 지역을 파악해 콘텐츠를 제공하는 경우: 원하는 지역의 서버에서 크롤러를 실행하거나 해당 지역의 프록시 서버를 경유해서 접근

 

---

SSL 통신 오류

SSL 의 개념>

en.wikipedia.org/wiki/Transport_Layer_Security

Transport Layer Security - Wikipedia

SSL 통신 오류 확인할 수 있는 사이트> www.ssllabs.com/ssltest/

SSL Server Test (Powered by Qualys SSL Labs)

SSL(TLS) 버전 별 출시 연도

 

• SSL 3.0 이전까지는 RFC에 의해 사용 중지됨
• PCI SSC도 TLS 1.0은 권장하지 않음
• 프로그래밍 언어에서 사용할 수 있는 통신 라이브러리에서도 TLS 1.0은 디폴트로 비활성화
• 오래된 웹 사이트 일부에서는 TLS 1.0이 아니면 통신 안되는 경우도 있음
• 따라서 웹 사이트를 개발할 때는 TLS 1.0을 사용할 수 밖에 없음
  • 크롤링 도중에 이유를 알 수 없는 SSL 통신 문제가 발생한다면 TLS 버전까지 확인 필요

 

SSL 지원 사이트 크롤링

• 일반적으로 프로그래밍 언어의 HTTP 통신 라이브러리는 SSL 지원
• 하지만 사내 서비스등 비용 문제로 스스로 발행한 SSL 인증서로 암호화하는 경우가 존재
  • 신뢰X → 브라우저 경고 발생
• 크롬 시큐리티 탭 확인
  • SSL 증명서 정보 확인 가능
• 실행 환경에 신뢰할 수 있는 키 저장소에 인증서를 추가해 문제 회피 가능
• 또는 옵션을 붙여 SSL 인증서 검증 비활성화 가능

keytool -importcert -v -trustcacerts -file /path/to/cert.crt -keystore $JAVA_HOME/jre/lib/security/cacerts /* 키 저장소에 인증서 추가 */

Response res = Jsoup.connect("https://www.example.com/")
	.validateTLSCertificates(false) /* SSL 인증서 검증 비활성화 */
	.execute();