HTTP와 HTTPS

- 프로토콜

 

한국어만 할 줄 아는 사람과 영어만 할 줄 아는 사람간의 의사소통이 가능할까. 누군가는 바디랭귀지 같은 소리하면서 가능할 수도 있다고 하겠지만 정확하고 심도있는 논의는 불가능할 것이다. 그리고 만약 화자가 사람과 사람에서 컴퓨터와 컴퓨터로 바뀐다면 언어가 다른 상황에선 아주 간단한 의사소통의 가능성 마저도 완벽히 차단될 것이다.

 

이처럼 네트워크 상에서 컴퓨터간의 정확한 정보 교환을 위해서는 공통된 언어가 필요하다. 이를 표준통신규약,  프로토콜이라고 한다. 프로토콜의 종류엔 여러가지가 있는데 월드와이드웹에서 사용되는  HTTP도 그 중 하나다

 

- HTTP (Hypertext Transfer Protocol)

 

HTTP는 서버와 클라이언트가 인터넷 상에서 데이터를 주고받기 위한 프로토콜이다. 주고받을 수 있는 데이터는 이미지, 동영상, 오디오, 텍스트 문서 등 종류를 가리지 않는다. 인터넷에서 모든 종류의 데이터를 접하고 보낼 수 있는 것도 모두 그 덕이다. HTTP를 만든 팀버너스리 옹과 당시 유럽 입자 물리학 연구소 팀원 여러분 감사..

 

이 프토토콜은 서버-클라이언트 모델, 요청 응답 방식을 따른다. 클라이언트가 서버에게 요청을 보내면 서버가 응답을 한 후 클라이언트와의 연결을 바로 끊는 방식인데 이 방식은 클라이언트와 서버 간의 최대 연결 수가 정해져 있다는 한계를 극복하는 데 유용하다.

 

예를 들어 최대 연결 수가 100인 서버 컴퓨터가 있다고 치자. 그렇다면 클라이언트가 100명 이하일 때는 문제가 없겠지만 ( 사실 100명이하여도 접속자수가 많아지면 속도가 느려지는 문제가 있을거다 ) 클라이언트가 100명이 넘어가면 아예 접속이 안되는 상황이 발생할거다.

 

그러나 요청-응답 방식은 클라이언트가 요청을 보낼 때만 서버와 연결이 되었다가 서버가 응답을 하면 바로 클라이언트와의 연결을 끊는 방식이기에 최대 연결 수가 100인 서버 컴퓨터도 100명 이상의 클라이언트의 요청을 처리할 수 있다. 즉 불특정 다수를 대상으로 하는 서비스에 적합한 방식이라는 얘기.

 

물론 응답 후 바로 연결을 끊어버리는 이런 특성 때문에 클라이언트가 이 전에 어떤 요청을 했는지 등의 상태는 알 수 없는 단점이 있다. 이러한 특징을 무상태 (Stateless)라고 하는데 이러한 부분을 극복하기 위해 Cookie와 같은 기술이 등장하였다.

 

이 때 클라이언트가 보내는 요청은 URL / URI를 이용하며 존재하는 자원에 대한 요청을 보낼 때(select)는 GET,  새로운 자원을 생성할 때(insert)는 POST, 존재하는 자원을 변경할 때(update)는 PUT, 존재하는 자원을 삭제할 때(delete)는 DELETE, 서버 헤더 정보를 획득할 때는 HEAD, 서버 옵션들을 확인하기 위해서는 OPTION 이라는 HTTP 요청 메서드를 서버로 보낸다. 

 

이런 클라이언트의 요청 메서드를 받을 경우 서버는 HTML 문서나 각종 리소스와 함께 HTTP 상태 코드를 반환한다. 200번대의 상태 코드는 대부분 성공을, 300번대의 상태코드는 대부분 리다이렉션을, 400번대 상태코드는 대부분 클라이언트 에러를, 500번대 상태코드는 서버 에러를 의미한다. 

 

클라이언트와 서버간의 이러한 요청 / 응답 내용은 크롬 브라우저를 사용하는 경우 개발자 도구를 통해 직접 확인할  수도 있다.  ( 참고 : https://zetawiki.com/wiki/%EA%B5%AC%EA%B8%80_%ED%81%AC%EB%A1%AC_%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90%EC%84%9C_HTTP_%ED%97%A4%EB%8D%94_%EB%B3%B4%EA%B8%B0 ) 후술할 HTTPS를 위해 마지막으로 하나만 덧대자면 HTTP에서는 이러한 서버와 클라이언트간의 정보 전송이 모두 평문(사람이 읽을 수 있는)으로 오간다. 

 

- HTTP vs HTTPS (HyperText Transfer Protocol over Secure Socket Layer)

 

인터넷 주소의 의미 ( URL / URI ) 포스팅 (https://takeknowledge.tistory.com/29)에서 URL의 가장 앞 부분 그러니까 :// 앞의 부분이 URL scheme, 자원에 접근할 방법을 정의해 둔 프로토콜 이름을 의미한다고 했다. 과거엔 이 부분이 대부분 http 였지만 지금 이 티스토리도 그렇고 요즘 대부분의 큰 사이트들은 http가 아닌 https로 시작하는 경우가 많다. http는 대충 알았는데.. 그럼 이건 뭘까?

 

자세하게 설명하자면 암호화 방법에 대한 설명까지 해야 하니 일단 개략적으로만 정리해보자면 일단 약자를 풀어썼을 때 HTTP부분은 똑같고 over Secure Socket Layer 부분만 추가된 것만 봐도 알 수 있듯 보안이 강화된 HTTP 정도로 유추해도 무방하다. 뒤의 Secure Socket Layer은 정확히는 SSL이라는 ( 사실 TLS 라고 부르는 게 IETF - 국제 인터넷 표준화 기구 - 표준이기에 더 정확하지만 아무튼 ) 암호화 프로토콜을 의미한다.  

 

위에 적었든 HTTP 통신은 평문으로 오가기에 메시지가 감청당하거나 데이터의 변조등이 일어나기 쉬운데 이런 점을 보완하기 위해 암호화 프로토콜인 SSL에서 돌아가는 HTTPS라는 프로토콜이 개발된 것이다.  현재 주로 쓰이는 HTTP 버전인 1.1에서는 보안 연결이 선택이지만 HTTP2에서는 사실상 필수가 된 만큼 HTTPS 점점 많은 사이트에 적용될 것으로 보인다.

 

( SSL에 관한 자세한 내용은 훗날 포스팅해서 링크를 더하겠습니다 )

 

참고 : 

[LECTURE] 2) 웹의 동작 (HTTP 프로토콜 이해) : edwith

프런트엔드 개발자가 알아야하는 HTTP 프로토콜 Part 1

HTTPS와 SSL 인증서 - 생활코딩