URI & URL
URI와 URL을 혼용해서 사용하는 경우가 있다. 두 차이를 정확히 몰랐는데, 이번 기회를 통해 비교할 수 있었다.
결론부터 보면, URI는 URL의 의미를 품고 있다.
▶ URI (Uniform Resource Identifier) : 자원의 위치 뿐만 아니라 자원에 대한 고유 식별자로서 URL 의미를 포함한다.
▶ URL (Uniform Resource Locator) : 자원이 실제로 존재하는 위치를 가리킨다.
즉, URI는 식별하고, URL은 위치를 가리킨다.
예를 들어보자.
1) https://withmoonlab.tistory.com/index
위의 예시에서 withmoonlab.tistory.com에서 index라는 경로를 타나내고 있다.
서버에서 해당 라우팅에 대한 자원을 전송해줄 것이며 이는 자원이 실제로 존재하는 위치이므로 URL이다.
2) https://withmoonlab.tistory.com/162
위의 예시의 경우, withmoonlab.tistory.com 에서 162의 ID 값을 가지고 있는 자원을 식별하고 있다.
따라서, 해당 예시는 URL이자 , URI라고 할 수 있다.
▶ HOST : 해당 위치에는 도메인 네임 혹은 IP 주소가 들어간다. 컴퓨터의 주소를 표시하는 영역이다.
▶ PORT : 컴퓨터에서 실행되고 있는 수많은 프로세스들의 주소이다. 기본적으로 포트번호를 입력하지 않았을 때는, 프로토콜이 가지고 있는 기본 포트번호가 적용된다. ( HTTP : 80, HTTPS : 443)
웹의 구성 요소
웹의 구성 요소 중 통신 중계 프로그램에 해당되는 요소들에 대해 정리하였다.
● 프록시 : 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램
<클라이언트 - 프록시 - 서버>
- 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 시스템이나 응용 프로그램이다.
- 프록시를 사용하면 보안 측면으로 이점이 있으며, 캐시 기능으로 성능을 향상시킬 수 있다.
- 프록시 종류 : 캐시 프록시, 포워드 프록시, 리버스 프록시 등
● 게이트웨이 : 네트워크 통신의 관문, 출입구
<클라이언트 - 게이트웨이 - HTTP 서버 이외의 서비스를 제공하는 서버>
- 프록시와 같이 클라이언트와 서버 사이의 중개자 역할을 한다.
- 프록시와 차이점 : 서로 다른 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 한다.
(위 그림에서 프록시의 경우 HTTP통신이나, 게이트웨이는 HTTP/POP 프로토코로 변환이 가능하다.)
*** 클라이언트의 HTTP와 서버의 HTTP가 버전이 다르기 때문에, 프록시도 프로토콜 변환이 가능하다는 얘기도 있어 프록시와 게이트웨이의 경계가 불명확하다고 한다.
● 캐시 : 프록시 서버에 보관된 리소스 사본과 클라이언트 로컬 디스크에 보관된 리소스 사본
- 사용 이유 : 리소스를 가진 서버(오리진서버)에의 액세스를 줄이는 것이 가능하다.
(= 통신량과 통신 시간을 절약할 수 있다) = 같은 데이터를 몇 번이고 오리진 서버에 전송할 필요가 없다.
- 캐시 서버는 프록시 서버의 일종으로 캐싱 프록시로 분류된다.
● 터널 : 서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속 주선하는 프로그램
- HTTP 프로토콜을 지원하지 않는 앱에게 HTTP 앱을 사용해 접근하는 방법을 제공한다.
- HTTP 커넥션을 통해 HTTP가 아닌 트래픽을 전송할 수 있고, 다른 프로토콜을 HTTP위에 올릴 수 있다.
- 대표적인 경우는, 클라이언트가 SSL과 같은 암호화 통신을 통해 서버와 통신하기 위해 사용하는 경우이다. (SSL 터널링)
쿠키와 세션
▶ 쿠키 : 웹사이트에 접속할 때 클라이언트 로컬에 저장되는 Key-Value쌍의 작은 데이터 파일
- 구성 요소 : 쿠키이름, 쿠키값, 만료시간, 전송할 도메인명, 전송할 경로, 보안연결여부, HttpOnly여부
[쿠키 동작 방식]
1. 클라이언트가 서버에 TEST 요청을 한다..
2. 서버는 클라이언트 요청의 유효성을 확인하고 응답 헤더에 set-cookie : ~ 를 추가혀 응답한다.
3. 클라이언트는 이후 서버에 요청할 때 전달 받은 쿠키를 자동으로 요청 헤더에 추가하여 요청한다.
▶ 세션 : 브라우저가 종료되기 전까지 클라이언트 요청 유지해주는 기술
- 각 클라이언트에게 고유 ID를 부여한다. (해당 ID로 클라이언트를 구분하여 요구에 맞는 서비스 제공 가능)
- 세션은 서버에 저장하기 때문에 저장공간이 필요하며, 부하가 발생할 수 있다.
- 보안이 취약한 쿠키의 한계점 극복을 위해 세션을 사용하며, 쿠키를 기반으로 동작하지만 사용자 정보를 클라이언트 측이 아닌 서버 측에서 관리한다는 점이 다르다.
<세션 동작 방식>
1. 클라이언트가 서버에 로그인 요청을 한다.
2. 서버는 클라이언트 로그인 요청에 대한 유효성 확인 후, 고유 ID와 SESSION ID이름으로 저정한다.
3. 서버가 응답할 때, 응답헤더에 set-cookie : ~ sessionid:~를 추가하여 응답한다.
4.클라이언트는 이후 서버에 요청할 때, 전달 받은 sessionid 값을 자동으로 요청헤더에 추가한다.
5. 서버에서는 요청헤더의 sessionid 값을 저장된 세션 저장소에서 찾아보고 유효한지 확인 후, 작업을 처리한다.
HTTP 비교
▶ HTTP 1.0
- 기본적으로 Connection당 하나의 요청을 처리할 수 있다.
- 동시전송은 불가능하고, 하나의 요청에 대한 응답이 온 후, 다음 요청 처리한다.
▶ HTTP 1.1
- 오늘날 가장 많이 사용되는 HTTP 버전 / HTTP Pipelining 도입
- HTTP1.0의 Latency를 개선하기 위해, TCP 안에 두 개 이상의 HTTP 요청을 담아 Network Latency를 줄인다.
- 문제점 : 정확한 구현이 힘들기 때문에 HOL Blocking이 발생한다.
* HOL Blocking이란?
Head of Line의 줄임말로서 앞선 요청에 의해 뒤에 요청이 지연되는 것을 의미한다.
HTTP Pipelining 을 통해 한 번에 여러 개 이미지 요청하는 경우, 가장 앞 이미지가 응답 지연되면 그 다음 이미지들 지연된다. TCP안에 여러 개의 HTTP 요청이 왔기 때문에 완료된 것 먼저 해결해서 응답을 보내면 되지 않을까 생각할 수 있지만 서버는 TCP에서 요청 받은 순서대로 응답을 해야한다.
▶ HTTP 2.0
- HTTP1.1 프로토콜을 계승해 동일한 API면서 성능 향상에 초점을 맞췄다.
- End-User가 느끼는 Latency나 네트워크, 서버 리소스 사용량 등과 같은 성능 위주로 개선되었다.
- Header Compression : 클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만
보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경령화 하였습니다.
- Stream Prioritization: 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결했다.
(ex. 문서 내에 CSS파일 1개와 이미지 파일 2개가 존재하고 이를 클라리언트가 요청하는 상황에서 이미지 파일보다 CSS 파일의 수신이 늦어진다면 렌더링에 문제가 생기게 되는데 이를 해결함.)
HTTP vs HTTPS
▶ HTTP (Hypertest Transfer Protocol)
- 클라이언트와 서버 사이에 이루어지는 request/response를 위한 프로토콜
- 웹브라우저와 서버간의 웹페이지와 같은 자원을 주고 받을 때 쓰는 통신 규약
- 일반 텍스트로 이루어진 HTML 문서를 주고 받는데 사용된다.
- 데이터가 평문으로 전송된다.
▶ HTTPS (HyperText Transfer Protocol over Secure Socket Layer)
- HTTP의 보안이 강화된 버전
- 소켓 통신에서 일반 텍스트를 이용하며, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다.
SSL vs TLS
▶ SSL (Secure Socket Layer)
- 보안 소켓 계층으로, 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜
- 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단한다.
- 클라이언트와 서버 간 핸드셰이크를 통해 인증이 이루어진다.
▶ TLS
- SSL에서 더욱 향상 되고, 안전한 버전이다.
▶작동 방식
- SSL은 개인정보 보호를 위해, 웹에서 전송되는 데이터를 암호화한다.
- 데이터를 가로채려해도 거의 복호화가 불가능하다.
- 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 도착하기 전 조작된 여부를 확인한다.
※ HTTPS = SSL / TLS (X)
: SSL/TLS는 보안 통신을 위한 보안용 프로토콜이고, HTTPS는 보안용 프로토콜에 HTTP를 얹어서 보안된 HTTP 통신을 하는 프로토콜이다.
대칭키 vs 비대칭키
▶ 대칭키 : 암복호화에 동일한 키 사용
<장점>
- 암호화방식 속도가 빠르다.
- 대용량 데이터 암호화에 적합하다.
<단점>
- 키를 교환해야하는 문제 (키 배송 문제)
- 키가 탈취 될 수 있는 문제
- 관리해야 할 키가 방대하게 많아진다.
▶ 비대칭키 : 암복호화에 서로 다른 키 사용
(공개키-모든 사람 / 개인키-각 사용자 보유)
<장점>
- 키 분배 필요 없다.
- 기밀성, 인증, 부인방지 기능 제공
<단점>
- 대칭키 암호화 방식에 비해 속도가 느리다.
참조
| https://www.charlezz.com/?p=44767
| https://captcha.tistory.com/50
| https://kanoos-stu.tistory.com/46
| https://liveyourit.tistory.com/183
| https://velog.io/@wiostz98kr/HTTP1.1%EA%B3%BC-HTTP2.0%EC%9D%98-%EC%B0%A8%EC%9D%B4-e2v4x4t1
| https://ssungkang.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-HTTP-11-VS-HTTP-20
| https://junhyunny.github.io/information/cookie-and-session/
| https://velog.io/@jch9537/Node.js-Session-Cookie
'Network' 카테고리의 다른 글
| 2-2) OSI 7계층 (0) | 2022.09.02 |
|---|---|
| 2-1) 프로토콜 (0) | 2022.09.02 |
| 1-1) 웹브라우저 동작 방식 (0) | 2022.08.31 |
| Wireshark를 통한 백도어 패킷 분석하기 (1) | 2021.08.18 |
| Drive by download (CVE-2016-0189) 공격 정리 (0) | 2021.07.14 |