-
[SW 정글 51일차] MIME 타입, CGI, datagram vs stream기타/SW 사관학교 정글 2021. 9. 22. 01:10
오늘은 소켓 인터페이스부터 웹 서버를 만들면서 중간에 간단하게 알고 넘어간 개념을 정리하려고 한다.
1. MIME (Multipurpose Internet Mail Extenstions) type
MIME type은 서버가 클라이언트에게 전송한 문서의 다양성을 알려주기 위한 매커니즘이다.
클라이언트는 리소스를 내려받았을 때 해야 할 기본 동작이 무엇인지를 결정하기 위해 MIME 타입을 사용한다.
이미지파일만 생각해도 jpg, gif, png 등 다양한 확장자가 존재하고 이미지파일 이외에도 text, video 등 다양한 리소스들이 존재한다.
이에 따라 수많은 MIME 타입들이 존재하고 서버는 정확하게 MIME 타입을 설정해주는 것이 중요하다.
MIME의 구조는 아래와 같다.
type/subtype
/로 2개 부분으로 구분되는데 왼쪽은 카테고리(text, image, video..) 혹은 멀티파트 타입이고 오른쪽은 각각의 타입에 한정되어 정해진 type을 가진다. 위 구조에서 spaces(띄어쓰기)는 허용하지 않는다.
MIME의 구조는 개별 타입과 멀티파트 타입으로 나뉜다.
개별타입에서 카테고리와 그에 대한 서브타입의 종류는 아래와 같다.
개별타입에 들어가는 문자열을 보면 우리에게 익숙한 것들이다.
그러면 멀티파트 타입은 무엇일까?
멀티파트 타입은 합성된 문서를 나타내는 방법이다.
HTML에서 Form과 POST 메서드의 관계에서 사용되는 multipart/form-data과 전체 문서의 하위 집합만 전송하기 위한 206 Partial Content 상태 메시지(Range헤더에 쓰여진 데이터 범위에 대한 요청이 성공적으로 응답되어 바디에 해당하는 데이터를 담고 있다는 것을 알려주는 것)와 함께 사용되는 multipart/byteranges가 있다.
2개를 제외하고는 HTTP가 멀티파트 문서를 다룰 수 있는 특정한 방법은 존재하지 않는다.
2. CGI (Common Gateway Interface)
CGI는 웹 서버와 클라이언트 간에 필요한 정보교환을 가능하게 해주는 일종의 웹 인터페이스이다.
CGI의 풀 네임을 보면 Interface라는 것을 알 수 있는데 웹 서버와 요청을 받아 처리해줄 로직을 담고 있는 애플리케이션 프로그램 사이의 인터페이스라고 할 수 있다.
즉, 특정 플랫폼(언어)에 의존하지 않고 외부 프로그램을 호출하는 것이다.
그러면 CGI는 왜 나오게 된 것일까?
CGI가 나오기 이전에는 단순히 클라이언트가 HTML, Image 같은 정적인 컨텐츠를 요청했고 요청을 받은 서버는 자신이 가지고 있는 정적인 컨텐츠를 찾아 응답만 해주면 됐다.
시간이 지나면서 클라이언트는 단순한 정적인 컨텐츠가 아닌 어떠한 로직이나 애플리케이션 프로그램의 실행 결과를 요구함에 따라 이를 처리할 수 있는 무언가가 필요했고 이를 해결하기 위해 CGI가 나온 것이다.
예를 들면, 회원가입을 보면 우리는 어떠한 form을 받아 값을 채우고 버튼을 눌러 회원가입 요청을 하면 서버는 단순히 정적인 컨텐츠를 응답해주는 것이 아닌 DB조회나 어떠한 로직에 의해 나온 결과값을 응답으로 보내주어야 한다.
위 그림은 CGI를 사용하는 클라이언트-서버 통신과정을 나타낸 것이다.
그림을 보면 웹 서버가 클라이언트에게 응답을 보내기 위해 사용자가 만든 애플리케이션 프로그램과 통신 해야 하는데 그것을 도와주는 인터페이스가 CGI라고 생각이 든다.
CGI의 장점과 단점은 아래와 같다.
CGI 장점
- 언어, 플랫폼 독립적이다(스펙만 준수하면 된다).
- 매우 단순하고 다른 server-side 프로그래밍 언어에 비해 advanced task를 훨씬 쉽게 수행할 수 있다.
- 재사용할 수 있는 CGI 코드 라이브러리가 풍부하다.
- CGI가 웹서버에서 실행될 때 안전하다.
- CGI 코드를 수행하는데 특정 라이브러리가 필요하지 않기 때문에 매우 가볍다.
CGI 단점
- 느리다(요청이 올 때마다 DB connection을 새로 열어야 한다).
- HTTP 요청마다 새로운 프로세스를 만들기 때문에 서버 메모리를 많이 잡아먹는다.
(servlet은 요청마다 스레드를 만든다.) - 페이지 로드 사이에 데이터가 메모리에 캐시될 수 없다.
CGI 이후에도 다양한 인터페이스가 발전되었는데 그에 대한 정리글은 아래의 블로그를 참고하면 좋을 것같다.
https://velog.io/@seanlion/cgihistory
3. Datagram Socket vs Stream Socket
Tiny 웹 서버를 구현할 때, Socket을 생성하는데 그 과정에서 socket의 type에 SOCK_STREAM이라는 것으로 설정한다고 써있다. 그 이외에 데이터그램(SOCK_DGRAM), 원시 소켓(SOCK_RAW)으로 설정이 된다고 하는데 이들의 차이점이 궁금해졌다.
원시 소켓은 보안 상 위험이 있기에 거의 사용된다고 하지 않는다.
그래서 여기서 자세한 설명보다는 아래의 링크에서 간단하게 개념만 알고 가면 좋을 것같다.
https://www.netinbag.com/ko/internet/what-is-a-raw-socket.html
일단은 간단하게 얘기해보면 Datagram Socket은 UDP 프로토콜을 기반으로 통신을 하는 것이고 Stream Socket은 TCP 프로토콜을 기반으로 통신하는 것이다.
그러면 더 자세히 알아보자.
먼저, 스트림(SOCK_STREAM) 소켓이다.
스트림(SOCK_STREAM) 유형은 연결 지향성으로 오류 또는 복제 없이 데이터를 송신하며 송신한 순서대로 데이터를 수신한다.
스트림(SOCK_STREAM)은 데이터 오버런(버퍼에 저장된 데이터가 메모리로 올라오기 전에 다음 데이터가 수신되는 경우에 발생하는 문제)을 방지하기 위해 흐름 제어를 하고 데이터의 레코드 경계를 설정하지 않고 데이터를 바이트 스트림으로 취급한다.
다음으로 데이터그램(SOCK_DGRAM) 소켓이다.
IP에서 데이터 전송의 기본 단위는 데이터그램인데 데이터그램은 기본적으로 헤더와 페이로드로 구성된다.
데이터그램(SOCK_DGRAM) 소켓은 비연결성으로 클라이언트의 프로토콜과 서버의 프로토콜 간에 end-to-end 연결을 설정하지 않는다.
데이터그램(SOCK_DGRAM) 소켓을 사용하면 데이터그램의 전달을 보장하지 않는(신뢰성이 없음) 독립적인 패킷으로 전달된다.
그래서 데이터가 유실되거나 복제될 수 있고 순서가 유지되지 않은 채 도착할 수 있다.
위 개념을 바탕으로 차이점을 설명하면 아래와 같다.
1. 스트림 방식은 클라이언트와 서버 사이에 마치 하나의 파이프가 형성되어 전이중(full-duplex) 연결성이 보장된다.
반면에 데이터그램 방식은 출발지(source)와 목적지(destination)을 기반으로 하여 비연결성으로 통신이 이루어진다.
2. 스트림 방식은 신뢰성과 데이터의 순서를 보장하는 방식이다. 반면에 데이터그램 방식은 신뢰성이 보장되지 않고 데이터의 순서가 유지되지 않는다.
이렇게 보면 데이터그램 방식이 단점만 보이는데 장점으로는 비연결성이기에 서로 연결하거나 해제 과정이 생략되어 빠른 통신이 가능하다.
[오늘의 나는 어땠을까?]
요즘은 잠 잠자는 시간이 이전보다 늘었다.
일부러 늘린 것은 아닌데 원래는 알람을 들으면 자동적으로 몸을 일으키고 씻으러 가는데 그렇게 힘들지 않았다.
하지만 요즘에는 알람을 들으면 10분만 더, 10분만 더 하다가 30분, 1시간을 더 잔다.
피곤함을 많이 느껴서 그런가...
아니면 의지가 조금 꺽인 것일까..
다시 의지를 다 잡고 이전처럼 알람을 듣고 몸을 일으키려고 하는데 잘 되지 않는다.
그래도 내일부터는 8시 30분까지 가야할 이유가 생겨서 억지로라도 기상을 할 수 있다.
하지만 건강이 최우선이기에 내가 무리한다는 것을 느끼는 순간에는 잠시 휴식시간을 주고 할 것이다.
건강하게 정글을 수료하고 목표를 이뤄내자.
<참고 자료>
https://velog.io/@seanlion/cgi
https://live-everyday.tistory.com/197
https://www.ibm.com/docs/ko/i/7.3?topic=characteristics-socket-type
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=mankeys&logNo=221296673493
'기타 > SW 사관학교 정글' 카테고리의 다른 글
[SW 정글 52일차] 오늘은 일기만.. (0) 2021.09.24 [SW 정글 52일차] Proxy (0) 2021.09.22 [SW 정글 추석 특집] Missing Semester 2일차 (0) 2021.09.21 [SW 정글 50일차] stdout 와 STDOUT_FILENO (feat. File Descriptor) (0) 2021.09.21 [SW 정글 49일차] Tiny 웹 서버 구현하기 (1) 2021.09.20