URI와 웹 브라우저 요청 흐름
URI vs URL vs URN
- URI는 Locator, name 을 분류할 수 있다. 즉, 자원을 식별하는 역할을 수행한다.
- URL = 리소스 위치
- URN = 리소스 이름
- 예를 들면 URN:ISBN:8960777331 도서 책 ISBN에서 사용하는 유즈케이스이다. 하지만, URN 이름만으로는 실제 리소스를 찾는데 방법이 보편화되어있지는 않다.
- 그래서 거의 대부분 URL을 사용한다고 생각하면 된다.
- 일반적으로 URL 분석은 아래 포맷을 따르게 된다.
- scheme://[userinfo@]host[:port][/path][?query][#fragment] 형태를 가지게 된다.
- scheme - 어떤 프로토콜을 사용할지 결정한다.
- userinfo - URL에 사용자정보를 포함해서 인증한다.
- host - 도메인명을 포함한다.
- query : key-value 형테로 제공이 되는데 일반적으로 query parameter, query string으로 불리며 포맷은 다음과 같다. q=hello&hl=ko, 웹 서버에 제공하는 파라미터, 문자형태라고 보면 된다. 특히, 의도에 따라 query 값을 불순하게 보내면 SQL injection을 보낼 수도 있다. 주의..
- fragment : html 내부 북마크라고 표현은 하는데 거의 안쓰는듯 하다.
웹 브라우저 요청 흐름
- 간단하게 웹 브라우저 요청 흐름에 대해 살펴보도록 하자.
- 요청 형태 중 하나를 가져와 봤다. Get /search?q=hello&hl=ko HTTP/1.1 HOST: www.google.com 요청을 google 서버에 보낸다.
- 이 요청 메시지를 OSI 7 계층 기반으로 보면 L7, L6, L5 (어플리케이션, 프레젠테이션, 세션 레이어)를 거치면 HTTP 프로토콜 형식의 메시지 타입을 결정하게 되지 사실상 통신은 L4부터 시작하게 된다.
- L4에서 TCP/IP 헤더값을 추가하고, L3에서 IP 헤더값을 추가하고 마지막으로 L2에서는 이더넷 헤더를 추가한다. 특히, CRC라고 불리는 트레일러는 일종이 데이터의 신뢰성을 보장하기 위해 전달되는 PDU에 추가하게 된다. (*PDU = Protocol Data Unit)
- 위 단계를 거쳐서 캡슐화를 진행하면 L1 거쳐서 아날로그 형태로 Client측과 통신을 하게 된다. 클라이언트측 컴퓨터는 게이트웨이 과정을 수행하여 라우팅하여 데이터를 포워딩하는 과정을 반복해서 Client측과 통신을 하게 되는 것이라고 생각하면 된다.
- 데이터를 받은 Client측에서는 헤더를 하나씩 제거하면서 L7까지 서버에서 응답한 데이터 값을 받아온 후에 아마 이런 형식이 될것이다. HTTP/1.1 200 OK Content-Type, Content-Length, <html><body> ... </body></html> 이런 구조가 될것이다.
- 결국엔 이 과정이 수행될 수 있는건 사전에 TCP socket으로 3-handshake를 통해 이루어진다.
- 브라우저 렌더링을 할때는 DOM + CSSOM = Render Tree 를 수행해서 크롬이면 블링크라는 렌더링엔진으로 화면을 그리게 된다.
- 그리고 브라우저 캐시를 담을때는 HTML 에서 meta tag인 cache-control 옵션을 사용하던지 CSS에서 이를 추가할 수 있는 방법이 있다.
(이건 몰라...)
TCP/UDP 패킷 유실
- 패킷은 왜 유실될까? 몇가지 이유가 존재한다.
- 네트워크 혼잡, 네트워크 트래픽이 최대 제한에 도달하면 네트워크 정체가 발생한다.
- 소프트웨어 버그가 있다.
- 네트워크 하드웨어로 소개되는 라우터, 스위치, 허브, 방화벽 및 컴퓨터와 같이 오래된 네트워크 인프라로 인해 전체적인 네트워크 속도가 느려지고 처리량이 저하되어 패킷 손실이 발생할 수 있다.
- 또, 악성 바이러스 공격이 원인일 수 있다. 네트워크 속도가 느려지는 경우가 된다.
- 시스템 메모리가 부족하고 용량이 MAX가 되어 리소스 과다 사용으로 인해 데이터 패킷을 버리게 된다.
- TCP
- TCP는 패킷 유실이 발생하면 ACK가 도착하지 않는다. 그래서 다시 ACK를 보낸다.
- TCP는 스트림 기반의 프로토콜이다. 그래서 패킷을 P1~P5 범위로 나누어서 보고 (조합 범위가 P1~P2 / P3~P5) 라고 가정했을 때 P3가 없으면 P1,P2까지 조립된 데이터 스트림을 받게 된다. 그렇지만, P4,P5 이미 받았지만 P3가 없으므로 조립하지 못한다. P3에 대한 ACK가 오지 않으므로 송신측에서 다시 요청을 하게 된다. 수신측에서 P3가 오게 되면 P3,P4,P5를 조립해서 스트림을 조합해서 받게 된다.
- UDP
- UDP는 패킷 유실이 발생하면 데이터그램 자체가 유실된다. 또, UDP 데이터 그램이 크기가 클수록 유실될 확률도 크다.
- 패킷을 나누어서 전송한다 하더라도 하나라도 유실되면 수신측에서 아예 패킷을 모두 받지 못한다.
- 그래서?
- UDP 레이턴시 = 네트워크 기기의 레이턴시
- TCP 레이턴시 = 네트워크 기기의 레이턴시 + (100%-패킷 유실률) * 재전송 대기 시간
- 결론적으로 TCP 레이턴시 중 재전송 대기 시간이 수백 밀리 초에 해당되기 때문에 네트워크 환경에 대해 좋지 않은 경험을 제공해줄 수 있다. (*네트워크 패킷 유실률은 일반적으로 20% 이하가 된다.)
- 레이턴시가 민감 or 패킷 유실이 있어도 괜찮은 게임용에서 UDP를 많이 사용한다.
- 다른 접근으로 TTL을 기록해두는 방법이 있다. IPv4 헤더에 TTL(Time To Live)이 존재하는데 TTL값은 IP 데이터그램이 인터넷 시스템 내에서 존재할 수 있는 시간의 상한선으로 볼 수 있다. TTL 필드는 데이터그램의 송신자에 의해 설정되며, 목적지까지의 전송 경로에 있는 모든 라우터들에 의해 그 값이 감소된다. default 255로 표기되며 패킷이 라우터를 통과 할 때마다 감소한다.
출처 :
https://dribbble.com/shots/15126018-Cloud-icon-for-digital-ecosystem-logo-design-symbol
'Computer Science > Network' 카테고리의 다른 글
| HTTP 메서드 (0) | 2021.12.07 |
|---|---|
| HTTP 기본 (0) | 2021.12.07 |
| 인터넷 네트워크 (1) | 2021.12.07 |
| Network08 :: 네임서버 (0) | 2020.09.28 |
| Network07 :: OSI 7 계층 (0) | 2020.09.26 |