YUDA't

# HTTP란

HTTP는 HyperText Trasfer Protocol이라 하여 클라이언트(Client)와 서버(Server) 사이에 이루어지는 요청/응답 통신 규약이다.

HTTP는 주로 HTML을 주고받을 때 사용된다. 클라이언트(웹브라우저)가 HTTP를 통해 서버에게 웹페이지나 그림을 요청하면, 서버는 이에 응답하여 필요한 정보를 클라이언트에 전달한다.


HTTP를 통해 전달되는 자료는 http://로 시작하는 URL로 조회할 수 있다. 

기본 포트는 80이다.


HTTP의 최초 버전은 서버로부터 페이지를 요청하는 GET 메소드 하나만을 가지고 있었으며 응답은 무조건 HTML 문서였지만, 이후 추가 메소드와 필드를 통해 더 효율적인 보안 프로토콜이 갖추어졌다. 




# HTTP의 메소드

가장 자주 사용되는 메소드는 GET, POST이며 그 외에 PUT, DELETE 등이 있다.


- GET 메소드

데이터를 가져올 때 사용한다.

요청 URL의 뒤에 변수를 포함시켜 서버에 전달할 수 있다.(다만 데이터가 URL에 노출되니 주의)

  

/test/demo_form.php?name1=value1&name2=value2

캐싱되거나 브라우저 기록에 남을 수 있다.

북마크될 수 있다.

중요 데이터를 처리할 때는 되도록 사용하지 않는다.

길이 제한(8KB)이 있다.

데이터를 가져올 때만 사용하며 데이터를 수정하지 않도록 한다.

- POST

데이터를 제출할 때 사용한다.

데이터를 URL에 노출하지 않고 요청 body에 데이터를 저장한다.


POST /test/demo_form.php HTTP/1.1

Host: w3schools.com

name1=value1&name2=value2

캐싱되거나 브라우저 기록에 남지 않는다.

북마크되지 않는다.

길이 제한이 없다.


- PUT

데이터를 생성/수정할 때 사용한다.

POST 메소드와 다른 점은, PUT 메소드는 멱등성(여러 번 적용하더라도 결과가 달라지지 않는 성질)을 지닌다는 것이다. 즉 동일한 PUT 메소드를 반복해서 요청하더라도 같은 결과가 나온다. 그에 반해 POST 메소드를 반복해서 요청할 경우, 같은 자원을 여러 번 생성하여 부작용을 초래할 수 있다.


- HEAD

응답 body가 없다는 것을 제외하면 GET 메소드와 똑같다. HEAD 메소드는 GET 메소드를 요청하기 전에 해당 메소드가 어떤 결과를 도출해낼 것인지 확인할 때(예를 들어 대용량 파일이나 응답결과를 받을 때) 유용하다.




# HTTP 응답 코드

클라이언트가 서버에 요청을 보내면 서버는 세 자리 수 응답 코드와 함께 응답을 보낸다. HTTP의 응답 코드 중 자주 볼 수 있는 것들은 다음과 같다.


- 2XX(성공)

200: OK

204: 클라이언트의 요구를 처리했으나 전송할 데이터가 없음

- 3XX(리디렉션)

- 4XX(클라이언트 오류)

400: Bad Request. 요청 실패. 문법상의 오류로 서버가 요청사항을 이해하지 못함

401: Unauthorized. 권한 없음.

404: Not Found. 문서를 찾을 수 없음.

- 5XX(서버 오류)

500: Internal Server Error. 서버 내부 오류.

502: Bad gateway. 게이트웨이 상태 나쁨.



# HTTPS

HTTPS(HyperText Trasfer Protocol over Secure Socket Layer)는 HTTP의 보안이 강화된 버전이다. HTTP와 같이 일반 텍스트를 전달하나 대신 SSL/TLS 프로토콜을 통해 세션 데이터를 암호화한다.


HTTP의 URL이 http://로 시작하듯, HTTPS는 https://로 시작한다. 

기본 포트는 443이다.


- SSL(Secure Socket Layer) 인증서

SSL 인증서는 클라이언트와 서버 간의 통신을 제3자(CA)가 보증해주는 전자화된 문서이다. 

* 검증된 CA 기관들로는 Comodo CA, GoDaddy, Let's Encrypt(무료), GlobalSign 등이 있다.


- 대칭키와 공개키

SSL에서 사용하는 암호화 종류로는 대칭키와 공개키 방식이 있다. 


대칭키 방식은 동일한 키로 암호화/복호화가 모두 가능하다. 그러나 송수신자가 같은 키를 가져야 하기 때문에 대칭키를 전달하는 과정에서 키가 유출된다면 위험할 수 있다. 이를 보완하기 위해 나온 것이 공개키 방식이다.


공개키 방식은 두 개의 키가 서로를 암호화/복호화한다. 예를 들어 A키로 암호화를 하면 B키로 복호화를, B키로 암호화를 하면 A키로 복호화를 하는 것이다. 메시지를 암호화하는 publick key는 사용자들에게 공개되며, 그것을 복호화하는 private key는 호스트만이 알고 있다. 이로써 키를 서로에게 전달할 필요가 없어 대칭키 방식보다 보안면에서 유리하다.

'개발 > web' 카테고리의 다른 글

재미있는 REST API 파라미터의 종류와 개요  (0) 2019.03.08
HTTP와 HTTPS  (0) 2019.02.13