모든 개발자를 위한 HTTP 웹 기본 지식_섹션1_인터넷_네트워크

기본 내용

• 인터넷 통신
  • 복잡한 인터넷 망: 수많은 서버 노드를 거쳐서 서버와 클라이언트가 통신을 하게 되는데(ex. 해저 광케이블), 이 복잡한 상황에 제대로 통신이 되기 위해 IP(인터넷 프로토콜)이라는 규약을 사용한다. 그럼에도 부족해서 TCP 존재.
• IP(인터넷 프로토콜)
  • 패킷(Packet: Package + Bucket): 패킷이라는 통신 단위로 데이터를 전달.
  • IP 패킷 정보에 출발지 IP, 목적지 IP 둘 다 들어가야 한다(출발지 IP는 다시 서버가 Response를 보낼때 필요하다).
  • IP 프로토콜의 한계
    • 비연결성(connectionlessness): 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송(destination 컴퓨터가 확 꺼져버린다든가)
    • 비신뢰성(unreliability): 중간에 패킷이 사라지면(중간 노드 서버가 확 꺼져버린다든가)?, 패킷이 순서대로 안오면?
    • 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?

=> 등 기타 내용은 강의 자료에 잘 나와있습니다.

도착지 Port 는 어떻게 알까?

• 대부분의 포트는 그 번호가 지정되어 있기에 생략 가능한 경우가 많다. 그러나 서버가 임의의 포트에 서비스를 등록한 경우, 반드시 그 포트 번호를 명시하여야만 접속 가능하다(URL에서 포트 번호를 명시해야만 함).
  • URL 구조: <스킴>://<사용자 이름>:<비밀번호>@<호스트>:/경로;<파라미터>?<질의>#<세그먼트>
  • 예를 들면 데이터베이스는 보통 3306 포트를 사용하는데, 이는 표준이 아니기에 대부분의 데이터베이스 접속시 포트번호를 반드시 명시해야 접속이 가능하다.

QUIC: UDP기반 전송 프로토콜

By Wikipedia: QUIC("퀵"으로 발음)은 범용 목적의 전송 계층 통신 프로토콜로서, 구글의 짐 로스킨드(Jim Roskind)가 처음 설계하였고, 2012년 구현 및 적용되었으며, 2013년 실험 확대로서 공개 발표되었고, 국제 인터넷 표준화 기구에 기술되었다. 여전히 인터넷 드래프트 상태이지만 QUIC는 구글 크롬에서부터 구글 서버에 이르는 모든 연결의 절반 이상에 사용된다. 마이크로소프트 엣지, 모질라 파이어폭스가 이를 지원하되 이를 기본값으로 활성화해두지는 않은 반면 사파리는 기본값으로 QUIC를 활성화하고 있다.

UDP 기반으로 전송 프로토콜을 만드는 이유

•  
• TCP의 한계와 문제점
  • 확장성 부족 (Options 필드)
  • 패킷에 손대는 일이 가능
  • 미들박스와 고착화 문제
• 새 프로토콜을 정의하는 것의 문제점
  • 멋진 새 프로토콜을 하나 정의했다고 해도 그것이 실험실 밖으로 나왔을 때 인터넷상에서 항상 전송 가능한지 보장이 안됨
  • 만들었다고 해도 실제 사용을 위해서는 해당 서버와 클라이언트가 모두 해당 프로토콜이 구현되어 있는 커널 내지는 커널 모듈을 설치해야 한다는 현실적인 문제가 존재.
• UDP를 사용하는 이유
  • UDP 헤더에는 포트 번호와 패킷 크기, 체크섬만 있고, 체크섬은 굳이 채워넣지 않아도 된다. 즉 남은 부분에 사용자가 사용자가 정의해서 사용할 수 있는 아주 확장성이 좋은 프로토콜이다(애초에 이름부터가 User Datagram Protocol).
  • 사용자 수준에서 프로토콜 스택이 작성 가능하다. 관리자 권한도 필요 없으므로 일반 사용자 권한 만으로 서버와 클라이언트 모두 작성할 수 있다는 장점.

QUIC 참고한 링크: https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/

도움된 질문