www에서 가장 중요한 기술 두가지는 HTML과 HTTP다.
이 둘은 웹을 발명할 때 함게 만들어졌다.
HTTP는 웹의 요소들이 서로 대화할 때 사용하는 프로토콜이다.
HTTP를 이해한다는 것은 웹이 어떻게 동작하는 것인지 이해한다는 것이며, 이를 이해해야 웹 프로그래밍을 어떻게 할지, 웹 서버를 어떻게 만질지, 네트워크는 어떻게 관리할지에 대한 뼈대가 된다.
35년 가까지 온갖 언어와 프레임워크가 등장했다가 사라졌어도 웹은 기본적으로 HTTP 를 베이스로 동작한다는 사실은 변하지 않았다. PC, 스마트폰, 아이패드 그리고 향후 비전프로, 스마트글라스 등 어떤 하드웨어가 등장해도 이 메인스트림은 유지될듯하다.
(그리고 어떤 차세대 프로토콜이 나와도 HTTP 를 기반으로 하거나, HTTP 의 약점을 보완하는 방향으로 진행될 것이므로 이를 이해하는 것은 학습적 투자가치가 있을 것)
HTTP가 무엇인지 그리고 서버, 캐시, 프록시 등 웹 구성요소들이 무엇인지 가볍게 살펴보도록 하자.
목차
1. HTTP
2. URI
3. MIME 타입
4. 트렌젝션
5. HTTP는 TCP/IP를 이용한다
6. 프록시
7. 캐시, 게이트웨이, 터널
[ 1. HTTP ]
전세계의 웹브라우저, 서버, 애플리케이션은 모두 HTTP(Hypertext Transfer Protocol)를 통해 대화한다.
HTTP 외에 인터넷에서 사용되는 FTP(파일 전송 프로토콜), TCP/IP(전송 제어 프로토콜/인터넷 프로토콜) 들도 하나의 규칙일뿐이다.
엄청난 양의 이미지, HTML 페이지, 영상들이 인터넷을 떠다닌다.HTTP는 웹서버로부터 이 대량의 정보를 대중들의 웹브라우저로 옮겨준다.
다양한 시스템들이 서로 호환되고, 신뢰성 있게 데이터를 주고받을 수 있도록 약속을 정하지 않는다면 우리는 전송한 혹은 전송된 파일이 손상되었는지, 왜곡되었는지, 중복되었는지 믿을 수가 없다.
반대로 HTTP가 있기 때문에 개발자들은 네트워크를 100% 믿고 애플리케이션 기능개발에만 집중할 수 있는 것이다.
흔히 얘기하는 웹서버도 사실 HTTP 프로토콜로 대화하기 때문에 HTTP 서버다.HTTP를 요청을 통해 들어온 인터넷 데이터를 저장해두었다가 클라이언트가 요청한 데이터를 HTTP 응답으로 제공하는게 웹서버다.
[ 2. URI ]
한편, 이런 데이터들 (HTTP를 통해 주고받는 HTML 페이지, jpg, pdf, word, mp4...)을 웹 리소스라고도 하는데 이들은 반드시 주소를 갖는다.
다시말해 웹서버는 웹리소스를 관리하고 제공하는 역할을 하며 이 리소스는 URI(uniform resource identifier) 라는 주소를 갖게 되고 클라이언트는 이 주소를 통해 컨텐츠들을 받아간다.
http://www.biz-ninza.tistory.com/index.html
이와 같이 http:// (스킴) www.biz-ninza.tistory.com (주소) /index.html (리소스) 이렇게 세 부분으로 이루어진 표준 포맷을 따르게 된다.
그런데 티스토리에서 글작성시 링크 삽입을 클릭하면 "URI" 가 아닌 "URL" 이라고 나오는데 뭔차이 일까??
URI는 식별자다. 즉 배송주소 같은 것.
이 식별 방식에는 URL 과 URN 이 있는데 각각 Locator 과 Name 을 의미한다.
이름에서 알 수 있듯 URL 은 우리가 흔히 사용하듯 리소스의 정확한 위치와 접근방법을 보여준다.
URN 은 리소스의 위치에 영향 받지 않는 이름이다. 위치를 말해주지 않는다.
urn:isbn:0451450523
이와 같은 책의 ISBN 같이 자원의 고유성만을 나타내게 되며, 그렇다는 것은 이 URN을 통해 리소스 위치를 분석할 수 있는 인프라가 필요한데 아직은 그런 인프라가 부재해서 URN 채택이 늦춰지고 있다.
정리하면, 티스토리는 URN은 거부하고 URL만을 채택하여 링크삽입시 URI 를 입력하게 하는 것!
[ 3. MIME 타입 ]
한편 컨텐츠는 다양한 형태가 될 수 있고 이를 구분하기 위해 우리가 MIME 타입을 붙여 통신한다.
// 이미지 파일 요청(request)
GET /images/logo.png HTTP/1.1
Host: example.com
Accept: image/png -- MIME 타입
// JSON 형식의 응답(response)
HTTP/1.1 200 OK
Content-Type: application/json -- MIME타입
{
"id": 1,
"username": "john_doe",
"status": "created"
}
클라이언트는 '이미지 파일 줘' 라고 웹서버에 요청하였고
웹서버는 '응 JSON 데이터 줄게' 라고 응답하고 있다.
만약 이를 안붙이면 브라우저나 서버는 서로가 무슨 데이터를 보냈는지 알 수가 없다.
예를들면 서버가 HTML 을 주었다면 렌더링하고, 파일을 주었다면 다운로드를 하거나 해야하는데 이를 명시하지않으면 "이게 뭔데 므 어쩌라고...?" 하는 상황이 될 수가 있는 것이다.
이와 같이 HTTP 에서는 MIME(Multipurpose Internet Mail Extensions) 을 붙여서 통신하는 수단을 제공한다.
한편, 형태에 Mail 이 붙은 이유는 초기에 각기 다른 전자메일 시스템에서 메시지가 오갈때 겪는 문제점을 해결하기 위해 설계된 규칙이기 때문이다. 원래 이메일 시스템에서 다양한 파일 형식을 전송하기 위해 만든것이 MIME인데 HTTP와 같은 다양한 인터넷 프로토콜에서도 데이터를 식별하는 데 채택된 것이다.
그러나 MIME 타입이 반드시 있어야하는 것은 아니라는 것
즉 그냥 단순히 헬스체크만 하거나, 단순히 '서버야 알아서 줄 것 줘' 라고 보내는 클라이언트의 GET 요청은 MIME 타입이 굳이 필요 없다.
다만 명확히 어떤 데이터를 주고받는지 명시가 필요한 자료의 경우에는 클라이언트는 Accept 헤더와 Content-Type 을 통해서 어떤 형식을 보내고 받을 것인지 지정하고, 서버는 내가 주는 데이터가 무엇인지를 Content-Type 을 통해 알려줘야한다.
[ 4. 트렌젝션 ]
클라이언트가 웹서버와 리소스를 주고 받는, 즉 요청과 응답을 받는 상호작용을 하나의 트렌젝션이라 볼 수 있다.
웹페이지는 이러한 여러가지 트랜젝션을 통해 가져온 리소스들의 모음이라고 볼 수 있다.
이러한 트렌젝션에서 HTTP 메서드를 통해 요청시 서버에게 어떤 동작이 취해져야하는지를 알려주고, 서버는 요청이 성공했는지 추가조치가 필요한지 등을 세자리 숫자의 상태코드로 알려준다.
또한 클라이언트와 서버는 요청과 응답메시지의 형식을 맞추어 메세지를 주고 받는데 형식은 비슷하다
// HTTP 요청 메시지 예시
GET /index.html HTTP/1.1 // 요청라인(시작줄)
Host: example.com // 헤더
User-Agent: Mozilla/5.0 // 헤더
Accept: text/html // 헤더
Connection: keep-alive // 헤더
// 본문없음// HTTP 응답 메시지 예시
HTTP/1.1 200 OK // 시작줄
Content-Type: text/html // 헤더
Content-Length: 1024 // 헤더
Server: Apache/2.4.1 // 헤더
// 이하 본문
<html>
<body>
<h1>Welcome to the homepage</h1>
</body>
</html>
너무나 익숙한 메시지이지만 하나씩 파고들면 이쪽 세계관도 상당한 고민의 흔적이 있다는 것을 깨닫게 된다.
나중에 알아보자.
[ 5. HTTP는 TCP/IP 를 이용한다 ]
이러한 메시지들은 TCP(Transmission Control Protocol) 커넥션을 통해 한 곳에서 다른 곳으로 옮겨진다.
통신 계층에서 HTTP는 Application 계층 프로토콜이다.
핵심적인 세부사항은 TCP/IP 에게 맡기는데 TCP/IP를 통해서 각 네트워크와 하드웨어의 특성을 숨기고 어떤 종류의 컴퓨터나 네트워크는 서로 신뢰성 있는 의사소통을 할 수 있게 된다.
TCP 커넥션이 일단 맺어지면 컴퓨터 간에 교환되는 메시지는 없어지거나, 손상되거나, 순서가 바뀌는 일은 결코 없으므로 HTTP는 이 채널에 통신을 위임하여 안정성있는 통신을 유지한다고 생각하자. (자세한 원리는 향후 연구대상으로 삼자)
TCP 커넥션을 맺는다고 하면 서버 컴퓨터에 대한 IP 주소와 그 서버에서 실행중인 프로그램이 사용중인 포트번호가 필요하다.
가령 http://biz-ninza.tistory.com:80 과 같은 주소에 요청을 보낸다고 하자.
1) 웹브라우저는 서버의 URL 에서 호스트명 biz-ninza.tistory.com 을 추출한다.
2) 웹브라우저는 호스트명을 IP로 변환한다.
3) 웹브라우저는 URL에서 포트번호를 추출한다.
4) 웹브라우저는 IP와 포트번호를 알았으니 웹 서버와 TCP 커넥션을 맺는다.
5) 웹브라우저는 드디어 서버에 HTTP 요청을 보낸다.
6) 서버는 웹브라우저에 HTTP 응답을 돌려주고 커넥션은 닫힌다.
7) 웹브라우저는 응답을 통해 받은 결과를 클라이언트에게 보여준다.
브라우저는 HTTP 방식을 채택해 TCP 커넥션을 맺고 HTTP 통신을 한다.
한편 텔넷을 사용해서 텍스트 기반으로 서버와 TCP 커넥션을 맺어 소통가능하다.
스파이더나 웹로봇도 브라우저처럼 HTTP 요청을 만들어주는 프로그램이다. 이를 에이전트라고 부른다.
즉 TCP 커넥션을 맺고 소통하는것은 HTTP만 뿐만이 아니며 HTTP는 브라우저에서만 사용되는 것도 아니다.
그저 웹 애플리케이션을 구현할 때 브라우저를 사용하여 서버와 HTTP 통신을 할 수 있는 것 뿐.
[ 6. 프록시 ]
클라이언트와 서버 사이에 위치한 HTTP 미들웨어. 클라이언트의 HTTP 요청을 대신 받아 서버에 전달한다. 주로 보안을 위해 사용하며 요청과 응답을 필터링한다. 예를들면 회사에서 무언가를 다운 받을 때 바이러스를 미리 검출하는 역할을 한다.
프록시는 캐시역할을 할 수 있다.
웹캐시와 캐시 프록시는 자신을 가쳐가는 문서들 중 자주 찾는 것의 사본을 저장해두는 특별한 종류의 HTTP 프록시 서버로 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고.
HTTP 트래픽을 다른 프로토콜로 변환할 때 사용하는 게이트웨이도 프록시 역할을 할 수 있다.
가령 HTTP/FTP 게이트웨이는 클라이언트와는 HTTP 를 이용해 통신을 하되 FTP 서버와는 FTP 통신을 한다 (클라이언트는 이 게이트웨이를 진짜 서버인 것처럼 생각한다)
터널도 프록시 역할을 한다고도 볼 수 있다. 단순히 HTTP 통신을 전달하기만 하는 일종의 특별한 프록시
HTTP 터널링은 HTTP 요청을 통해 다른 프로토콜 (HTTPS, FTP, SMTP 등) 로의 통신을 가능하게 해준다. 주로 비 HTTP 데이터를 HTTP 연결을 통해 전송하는데 사용된다.
가령 위와같이 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송함으로써 웹 트래픽만 허용하는 방화벽을 우회하거나 네트워크 제한을 피하기 위해 터널을 사용할 수 있다. 이후 HTTP 요청을 받아들여 목적지의 주소와 포트번호로 커넥션을 맺는다. 이후엔 암호화된 SSL 트래픽을 HTTP 채널을 통해 목적지 서버로 전송할 수 있게 된다.
한마디로 HTTP 가 아닌 것들도 HTTP처럼 지나게 하는것
[ 7. 캐시, 게이트웨이, 터널 ]
캐시, 게이트웨이, 터널도 프록시의 역할을 할 수 있는 것이지만 정확한 정의는 다음과 같다.
프록시 : 클라이언트와 서버 사이에서 요청과 응답을 중개하는 요소
- HW : F5 BIG-IP 로드밸런서
- SW : Nginx
캐시 : 자주 사용되는 데이터를 임시로 저장하여 빠른 응답을 제공하는 기술
- HW : CPU 캐시, 디스크 캐시
- SW : Redis, 브라우저 캐시
게이트웨이 : 서로 다른 네트워크, 시스템, 프로토콜을 연결하는 중간장치. 단일 인입점을 제공하며 인증, 권한체크, 로깅등을 수행
- HW : 라우터, 인터넷 게이트웨이 장비
- SW : Spring Cloud Gateway, AWS API Gateway
터널 : 클라이언트와 서버간 네트워크 통신을 보호하기 위해 데이터를 암호화하거나 특정 경로로 트래픽을 라우팅하는 기술
- HW : VPN 라우터
- SW : OpenVPN, SSH 터널링
참고로 HTTP 프로토콜은 버전이 여러가지다. 디벨롭되고 있다.
언젠간 버젼별 차이도 정리할 필요성이 있을 것
출처 - HTTP 완벽가이드
'아카이빙 > 인프라' 카테고리의 다른 글
| [모른다면 클릭] 쿠키 딥다이브 (feat. Version 0 쿠키, 써드파티 쿠키, Cache-Control과 쿠키) (1) | 2025.02.14 |
|---|---|
| HTTPS를 왜 써야하는지, 암호화가 뭔지 모른다면 클릭 (0) | 2025.01.30 |
| 아직 웹서버와 WAS 구분이 안된다면 클릭 (1) | 2025.01.07 |