웹 프로토콜이란?

웹 프로토콜은 웹에서 쓰이는 통신 규약이다. 통신 규약이라는 것은 쉽게 설명하면, 통신을 할 때 '내가 이렇게 할게. 너는 이렇게 해줘!'라고 약속하는 것이다.

웹 프로토콜에는 다양한 것들이 있지만 해당 포스팅에서는 HTTP, FTP, SMTP, MIME만 다룬다.

1. HTTP(Hyper Text Transfer Protocol)

HTTP는 브라우저가 웹서버와 통신하기 위해 사용하는 주요 프로토콜이다.
즉, 인터넷에서 데이터를 주고 받을 수 있는 통신규약 정도로 생각하면 된다.

HTTP의 특징

• 암호화 되지 않은 평문 데이터를 전송하는 프로토콜이다.
  → HTTP로 보안이 중요한 데이터를 주고 받으면 제 3자가 정보를 조회할 수 있다. 즉 보안 취약
  

• 상태가 없는(stateless) 프로토콜이다.
  → 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리 된다는 말이다. 좀 더 쉽게 말해서 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 말이다.

  이러한 특징 덕분에 서버는 세션과 같은 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 처리 및 서버의 부하를 줄일 수 있는 성능 상의 이점이 있다.

• HTTP는 일반적으로 TCP/IP 통신 위에서 동작하며 기본 포트는 80번이다.

• start line(method, path, version), headers, body 등으로 구성된다.

HTTP 통신 방식

HTTP로 데이터를 주고 받기 위해서는 클라이언트가 요청을 보내고 서버가 응답을 받는다. (여기서 클라이언트는 일반적으로 웹 관점에서는 브라우저를 의미하고, 서버는 데이터를 보내주는 원격지의 컴퓨터를 의미한다.)

예시) URL에 사이트 주소를 입력하고 확인을 누르면, 브라우저에서 GET 요청으로 서버에 페이지를 요청한다. GET요청을 받은 서버에서는 헤더와 요청한 문서를 클라이언트로 보낸다.

1.1 HTTP Request

HTTP request 메세지는 크게 3부분으로 구성된다.

• start line
• headers
• body

1.1.1 Start line

예시) GET /search HTTP/1.1

• HTTP Method: 해당 request가 의도한 action을 정의하는 부분
• Request target: 해당 request가 전송되는 목표 URI
• HTTP version: 사용되는 프로토콜의 버전. 1.0, 1.1, 2.0 등이 있다.

1.1.2 Headers

해당 request에 대한 추가 정보를 담고 있는 부분

• key : value 값으로 되어 있다.
• Headers도 크게 3부분으로 나뉘지만(general headers, request headers, entity headers) 너무 자세한 부분으로, 3부분으로 나뉜다는 점만 알고 있자.

예시)
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json
Content-Length: 257
Host: google.com
User-Agent: HTTPie/0.9.3

자주 사용되는 header 정보는 다음과 같다.

• Host: 요청이 전송되는 target의 host url
• User-Agent: 요청을 보내는 클라이언트에 대한 정보
• Accept: 해당 요청이 받을 수 있는 응답(Response) 타입
• Connection: 해당 요청이 끝난 후에 클라이언트와 서버가 계속해서 네트워크 커넥션을 유지할 것인지 아니면 끊을 것인지에 대해 지시하는 부분
• Content-Length: 메세지 body의 길이

1.1.3 Body

해당 request의 실제 메세지/내용이다. body가 없는 request도 많다.(ex. GET request 대부분)

예시)
{
    "imp_uid": "imp_1234567890",
    "merchant_uid": "order_id_8237352",
    "status": "paid"
}

1.2 HTTP Response

Request와 마찬가지로 크게 3부분으로 구성되어 있다.

• Status line
• Headers
• Body

1.2.1 Status Line

Response의 상태를 간략하게 나타내주는 부분이다.

예시) HTTP/1.1 404 Not Found

• HTTP version
• Status code: 응답 상태를 나타내는 숫자 값
• Status text: 응답 상태를 간략하게 설명해주는 상태 문자 값

1.2.2 Headers

• Response의 headers와 동일하다.
• 다만 response에서만 사용되는 header 값들이 있다.
• 예를 들어, User-Agent 대신에 Server 헤더가 사용된다.

1.2.3 Body

• Response의 body와 일반적으로 동일하다.
• Request와 마찬가지로 모든 response가 body가 있지는 않다. 데이터를 전송할 필요가 없을경우 body가 비어있게 된다.

1.3 자주 쓰이는 HTTP method

요청하는 데이터에 특정 동작을 수행하게 하고 싶을 때 사용하는 메서드로 HTTP Verbs라고도 불린다.

• GET: 존재하는 자원에 대한 요청(조회)
• POST: 새로운 자원을 생성
• PUT: 존재하는 자원에 대한 (전체) 변경
• PATCH: 존재하는 자원에 대한 (일부) 변경
• DELETE: 존재하는 자원에 대한 삭제
• HEAD: 서버 헤더 정보를 획득. GET과 비슷하나 Response Body를 반환하지 않는다.
• OPTIONS: 서버 옵션들을 확인하기 위한 요청. CORS에 사용한다.

1.4 자주 쓰이는 HTTP 상태 코드

URL과 요청 메서드가 클라이언트에서 설정해야할 정보라면 HTTP 상태코드는 서버에서 설정해주는 응답 정보이다. 상태코드는 200번대부터 500번대까지 다양하게 있지만 주요한 상태 코드만 몇 개 살펴보자.

2xx - 성공

200번대의 상태 코드는 대부분 성공을 의미한다.

• 200 : GET 요청에 대한 성공
• 204 : No Content. 성공했으나 응답 본문에 데이터가 없음
• 205 : Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고
• 206 : Partial Conent. 성공했으나 일부 범위의 데이터만 반환

3xx - 리다이렉션

300번대의 상태 코드는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우이다.

• 301 : Moved Permanently, 요청한 자원이 새 URL에 존재
• 303 : See Other, 요청한 자원이 임시 주소에 존재
• 304 : Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인

4xx - 클라이언트 에러

400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우이다.

• 400 : Bad Request, 잘못된 요청
• 401 : Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우
• 403 : Forbidden, 서버에서 해당 자원에 대해 접근 금지
• 405 : Method Not Allowed, 허용되지 않은 요청 메서드
• 409 : Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌

5xx - 서버 에러

500번대 상태 코드는 서버 쪽에서 오류가 난 경우이다.

• 501 : Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우
• 503 : Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우

1.5 브라우저에서 캐싱하기

웹 페이지 성능을 최적화하려면 캐시를 이용한다.

예를 들어, 용량이 큰 이미지가 많은 사이트를 반복 접속하는 경우에 다운로드 시간과 HTTP GET 요청 수를 줄이기 위해 해당 이미지를 사용자의 디스크에 저장하고 캐시로 사용한다.

브라우저는 캐시가 최신 버전인지 이전 버전인지 어떻게 확인할까? 바로 캐시는 사용하기 전에 서버에 HEAD 요청을 날려 Last-Modified Date을 비교해 최신임을 확인한다.

여기서 주의할 점은 모든 파일에 대해 캐시를 만드는 것이 더 효율적일지 아니면 HEAD 요청을 만들어 날리는 값들을 고려했을 때 캐시로 만들지 않는 것이 더 효율적인지 고민해야 한다. (캐시하려는 파일의 크기가 매우 작은 경우)

2. FTP(File Transfer Protocol)

파일이 문서, 이미지, 프로그램 등 다양한 형태의 데이터를 갖고 있을 수 있기 때문에 컴퓨터 간의 파일 교환시에 호환성을 보장하는 프로토콜이 필요하다.

컴퓨터 간의 호환성이라는 것은 예를 들어, 한 컴퓨터에서는 JPEG 이미지가 .jpg로 저장되지만 다른 컴퓨터에서는 .jpeg로 저장될 수 있다. 또한 어떤 컴퓨터는 파일 경로를 (/)를 사용하지만 다른 컴퓨터는 ()를 사용할 수도 있다.

그렇기 때문에 파일 전송에 대한 규약인 프로토콜을 사용하여 상호 컴퓨터 간에 파일 전송이 가능하다.

특징

• 어떤 형태의 데이터든 전송이 가능하다.
• 파일을 다운로드 & 업로드 할 수 있다.
• 파일에 대한 권한을 설정할 수 있다.
• ASCII 문자로 메시지가 교환된다.
• 파일을 검색하고 조회할 수 있다.

브라우저에서 파일을 다운로드하게 되면 바로 FTP 프로토콜을 사용하게 된다.

통신 방식

HTTP와 달리 FTP는 클라이언트에서 서버와의 연결이 맺어지면 해당 연결은 명령어 입력을 위해 남겨놓고(Control Connection), 파일을 보낼 때 새로운 연결을 추가하여 파일을 전송한다.(File Connection)

3. SMTP(Simple Mail Transfer Protocol)

메일 전송 프로그램이 서버로 메일을 보낼 때 사용하는 프로토콜이다.

특징

• 오직 텍스트만 전송이 가능하다.
• 스트림 방식을 이용하여 전송한다.
• 한 개의 메시지를 해당 서버의 여러 수신자에게 보낼 수 있다.
• 상태 코드는 250(수신 성공), 550(수신자 못 찾음)이 있다.

4. MIME(Multi-purpose Internet Mail Extensions)

SMTP로 전송시 이메일에 텍스트 밖에 포함하지 못하는 단점을 보완하여, 메시지 안에 텍스트 이외의 데이터를 전송할 수 있도록 하는 프로토콜이다.

특징

• 바이너리 파일을 출력 가능한 문자열 형태로 인코딩하고, 수신하는 부분에서 디코딩한다.
• Base64로 인코딩하기는 하지만, 다른 형태의 인코딩도 사용할 수 있다. (인코딩 방식은 메시지의 헤더 안에서 정의)

MIME은 이메일 헤더에 2줄을 추가한다. 이메일에 MIME이 사용되었는지 여부와 MIME 정보를 바디에 어떻게 포함시킬 건지를 정의한다.

MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=Mime_separator

위의 MIME 버전은 1.0이고, 각 메시지 앞에 Mime_separator가 나타남을 명시한다. 텍스트만 보내는 경우엔 Content-Type이 text/plain이 된다.

결론적으로, MIME은 이메일 메시지 안의 헤더에 추가 정보를 포함하여 비텍스트 형의 데이터가 전송될 수 있도록 하는 프로토콜이다. 그리고 첨부된 데이터는 출력 가능한 형태의 문자열로 인코딩 되어 있고, 각 첨부 앞에 separator로 구분되어 있다.

---

📚 Reference

• https://velog.io/@teddybearjung/HTTP-%EA%B5%AC%EC%A1%B0-%EB%B0%8F-%ED%95%B5%EC%8B%AC-%EC%9A%94%EC%86%8C
• https://joshua1988.github.io/web-development/http-part1/
• https://joshua1988.github.io/web-development/web-protocols/