HTTP

서버와 클라이언트가 데이터를 주고받을 때 사용하는 프로토콜입니다.

• 구글, 유튜브, 네이버 등 많은 웹사이트들은 텍스트, 이미지, 동영상과 같은 데이터들을 HTTP를 이용해 주고 받습니다.

• HTTP를 통해 주고받는 데이터에는 JSON, XML, 텍스트 기반 데이터 그리고 바이너리 데이터가 있다.

• 텍스트 기반 데이터에는 웹페이지를 구성하는 HTML, CSS, JavaScript가 있다.

• 바이너리(이진수) 데이터에는 이미지, 영상, 파일 등이 있는데 모두 HTTP로 주고 받을 수 있는 데이터다.

HTTP 특성

무상태성 (Stateless)

HTTP 서버가 클라이언트 요청에 대해 아무것도 기억하지 않아도 되는 특성

• HTTP는 요청 메세지를 보내기 전까지 대상 컴퓨터가 연결 가능한지, 메세지를 응답할 수 있는 상태인지 알 방법이 없다.

• 모든 HTTP 메세지는 요청(request)과 응답(response)이 일대일로 대응해야 한다. 따라서 요청을 받은 서버는 반드시 응답을 보내야만 한다.

• 클라이언트는 자신이 보낸 요청이 성공했는지 실패했는지 알 수 있어서 로직이 단순해지는 장점을 가진다.

• 하지만 클라이언트는 서버로 HTTP 요청을 보내기 전에는 실제로 서버가 동작하는지 알 수 없다. 또한 서버가 요청을 받더라도, 클라이언트가 지정했던 시간 안에 응답을 보내지 못하는 상황도 있을 수 있다. 그래서 클라이언트 컴퓨터는 이러한 상황에 대해서 에러 메세지(404)를 보내주거나, 아니면 사용자는 새로 고침을 눌러 요청을 재시도 할 수 있다.

• 서버가 응답하는데 시간이 많이 걸리는데, 사용자가 기다리지 않고 계속 새로고침 하는 경우도 있다. 그래서 개발자는 서버 응답 시간과 최대 재시도 횟수, 평균적 부하, 실패 확률들을 고려해서 만들어야 한다.

• HTTP는 하나의 응답과 하나의 요청이 일대일로 대응하지만, 이전의 요청과 다음의 요청과는 연결되지 않는다. 이걸 비연결식이라고 한다.

TCP와의 비교

• 무상태성인 HTTP와 달리 전송 제어 프로토콜인 TCP(Transmission Control Protocol)는 상태가 있다.

• TCP는 연결을 끊지 않고 명시적으로 연결을 닫기 전까지 메세지를 계속 주고 받는다. 한쪽에서 문제가 발생하거나 주고받을 메세지가 없기 전까지는 연결을 계속 유지하여, 연결을 맺는 순간과 끊는 순간을 서버와 클라이언트 모두 알 수 있다.

TCP 장점

• 비연결 방식인 HTTP는 클라이언트나 서버의 연결이 끊겨도 끊긴지 알 수 없다. 그러면 클라이언트는 끊긴 줄 모르고 계속 요청을 보내고, 다른 클라이언트로 데이터를 전달하는 서버는 끊긴 줄도 모르고 계속 응답을 하는 상황이 와서 과부하때문에 전체적인 속도가 느려질 수 있다. 따라서 채팅처럼 실시간으로 데이터를 주고 받는 상황에서는 비연결 방식인 HTTP보다 지속적으로 연결 방식인 TCP를 많이 사용한다.

• TCP는 텍스트가 아닌 바이너리 데이터를 사용하지만, HTTP는 텍스트 기반과 바이너리 데이터 모두를 사용해서 패킷(네트워크를 통해 전송하기 쉽도록 자른 데이터의 전송 단위) 크기가 상당히 크다.

• TCP는 HTTP보다 패킷 크기가 가벼워서 데이터 처리 속도가 더 빠르다.

• TCP는 실시간 채팅, 실시간 멀티플레이 게임이나 주식처럼 빠른 시간에 많은 데이터를 주고 받을 때 사용된다.

TCP 단점

• 하지만 TCP를 사용하려면 개발자가 연결 상태를 직접 관리해야 한다. 왜냐하면 HTTP에서는 각 요청이 소켓 1개를 사용하지만, TCP는 모든 요청이 소켓 1개를 사용한다. 때문에 별도로 ID나 식별자를 사용하지 않으면 각 요청에 해당하는 응답을 구분할 수 없다.

• 프로토콜에서 응답이 왔는지 안왔는지 확인할 방법이 없어서 타임아웃 기능(HTTP 응답을 받지 못해서 응답 없음이라고 뜨는 기능)을 직접 구현해야 한다.

• 특히 연결이 자주 끊어지는 모바일 네트워크에서는 TCP를 사용할 때 조심해야 한다.

결론

• TCP는 HTTP보다 빠르고 가볍지만, 개발자가 연결 상태를 직접 관리해야 해서 설계를 잘 해야 한다.

• HTTP는 설계는 간단하지만, 느리다.

• 서버와 클라이언트가 주고 받는 메세지 양이 많다고 하여, TCP를 고집해야 하는 건 아니다. 서버를 늘리면 되고, 주문 처리, 로그인 인증 과정 등 연결 부분을 제외한 실질적인 서버의 동작 시간 자체는 둘 다 비슷하다.

• 대부분의 웹사이트는 메세지 통신으로 인한 데이터 처리하는 시간이 많이 걸리는게 아니라, 프로그램 내의 로직과 기능이 동작하는 시간이 많이 걸리기 때문에 프로토콜을 바꾸는게 큰 차이가 없다.

요청 메서드

1. GET

• GET 메서드는 웹 브라우저가 서버에 웹 페이지를 요청할 때 사용한다.

• 읽기 요청에 해당한다.

• 웹 사이트 주소를 입력해서 페이지에 접속할 때를 보면, GET 메서드로 요청하여 서버로부터 페이지를 구성하는 HTML, CSS, JavaScript를 가져와 브라우저로 보여주는 방식이다.

• GET 메서드는 요청 주소에 ?와 & 문자를 구분자로 사용하는 쿼리 파라미터를 추가할 수 있다.

• ? 문자는 첫 번째 파라미터를 구분할 때, & 문자는 파라미터 사이를 구분할 때 사용한다.

https://www.google.com/search?q=자바스크립트&rlz=1C5CHFA

• 위에서 q는 자바스크립트고 rlz=1C5CHFA를 나타낸다. 파라미터는 q와 rlz이다.

2. POST

• 클라이언트에서 서버로 데이터가 포함된 요청을 보낼 때 사용한다.

• 로그인, 장바구니 기능을 할 때 POST가 사용된다.

3. DELETE

• 데이터 삭제

4. PUT

• 데이터 수정 요청

기술적으로 DELETE와 PUT은 POST와 큰 차이 없다.

HTTP 요청(Request) 헤더

클라이언트에서 설정하는 헤더

• Host : 요청하는 호스트에 대한 호스트명 및 포트번호 (필수)
• User-Agent : 클라이언트의 브라우저, OS 정보
• Referer : 바로 직전에 머물렀던 웹 링크 주소
• Cookie : 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
• Origin : 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타낸다.
  여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
• Accept : 클라이언트가 허용할 수 있는 파일 형식
  ex) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/ ;q=0.8

HTTP 응답(Response) 헤더

서버에서 설정하는 헤더

• Server : 서버 정보 ex) Server : Apache
• Set-Cookie : 서버측에서 클라이언트에게 세션 쿠키 정보를 설정
• Cache-control : 캐시 관리에 대한 정보
• Content-type : 응답하는 내용의 타입과 문자 포맷
• Status code : 서버가 요청을 제대로 처리했는지의 여부

대부분의 서버는 해킹 방지를 위해 서버 정보를 숨긴다.

HTTP Status code

100 : 추가 정보가 있다.
200 : 요청이 성공적으로 처리되었다.
300 : 요청한 곳의 주소가 바뀌었거나 다른 장소로의 요청을 나타낸다.
400 : 요청처를 찾을 수 없어 처리할 수 없다(URL 혹은 클라이언트의 문제).
500 : 서버 측의 문제로 처리할 수 없다.

URL

• Uniform Resource Locator : 웹 요청 주소

• HTTP에서 통신할 대상을 식별할 때 사용한다.

• URL 주소는 사람들이 읽기 쉽게 만든 식별자다. 실제로 두 컴퓨터가 통신할 때 사용하는 것은 IP이며, 통신을 위해서는 URL을 IP 주소로 바꿔서 사용한다.

쿠키를 사용하는 이유

• 무상태성을 가진 HTTP는 TCP와 달리 이전에 어떤 요청을 보냈는지 알 수 없다.

• IP와 포트 주소, 요청 헤더의 Host 값으로는 이전의 요청과 새 요청을 완벽하게 구분할 수 없다.

• 따라서 HTTP 웹 서버는 쿠키와 세션 ID를 통해 클라이언트를 구분하고, 그 클라이언트가 새 요청을 보내는지 이전에 보낸 요청이 있었는지를 알 수 있다.

• 쿠키는 메모리에 계속 쌓여서 너무 많아지면 메모리가 가득 차서 프로그램이 느려질 수 있다. 따라서 쿠키를 생성할 때 만료 시간도 지정해서 만료 시간이 지나면 쿠키를 자동적으로 삭제한다.

• 쿠키는 오래 남을 수 있어서 해커들이 자주 공격하는 곳이다. 해킹을 방지하기 위해서는 쿠키를 보호할 수 있는 HTTPS를 사용해야 한다.

아파치와 Nginx

• 개발자가 HTTP 표준에 부합한 웹 서버를 처음부터 만드는 것은 매우 어렵고 비효율적인 일이다. 캐시, 압축 파일, 보안, 요청과 응답 등 고려해야 할 게 너무도 많다.

• 아파치와 Nginx는 HTTP 표준에 부합하는 웹 서버와 기능을 바로 사용할 수 있도록 도와주는 웹 서버 소프트웨어다.

• 아파치는 Nginx보다 오래 됬고, 웹 서버로서 안정성이 입증됬고 많은 기능들을 제공한다.

• Nginx는 아파치보다 뛰어난 성능과 가벼운 구조로 인기가 많다.

• 아파치는 사용자가 많아질수록 처리가 비효율적인 다중 프로세스 구조를 사용하지만, Nginx는 수평적 확장에 유리한 단일 스레드와 이벤트 기반으로 동작하여 많은 사용자를 처리할 수 있다.

• Nginx를 추천!

출처 : 학교에서 알려주지 않는 17가지 실무 개발 기술