[인프런][HTTP] 인터넷 네트워크

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

• 인터넷 통신
• IP (인터넷 프로토콜)
• TCP, UDP
• PORT
• DNS

 

• 인터넷 네트워크
  • 두 대의 컴퓨터가 통신을 한다
  • 케이블로 연결되어 있으면 통신이 어렵지 않다
  • 그러나 우리는 인터넷을 통해 통신을 한다
  • 인터넷은 복잡하다
  • 어떻게 수 많은 노드를 거쳐 통신을 할까?

 

• IP (인터넷 프로토콜)
  • 인터넷을 통해 데이터를 전송하기 위한 최소한의 규칙이 필요하다
  • 그것이 IP 주소
  • 클라이언트/서버는 IP 주소를 부여 받아야함
• IP 프로토콜의 역할
  • 지정한 IP로 데이터를 전달
  • 패킷 단위
• IP 프로토콜 패킷
  • 패킷에 전송할 데이터와 source IP, destination IP를 작성
  • 인터넷으로 패킷을 던짐
  • destination IP로 패킷이 전달됨
  • source IP로 데이터를 받았다는 응답(OK)이 전달됨
• IP 프로토콜의 한계
  • 비연결성
    - (컴퓨터 전원이 꺼져있는 등) 패킷을 못받는 대상에게도 패킷은 전송됨
  • 비신뢰성
    - packet loss?
    - out of order?
  • 프로그램 구분
    - 같은 IP 서버에 여러 애플리케이션이면?

 

• TCP
  • IP 프로토콜의 한계를 해결해줌
  • 프로토콜 4계층
    - 애플리케이션 계층 -> 전송 계층 -> IP 계층 -> 네트워크

• 프로토콜 계층
  • OS에서 제공하는 Socket 라이브러리를 사용
  • TCP 정보 + IP 정보 + 이더넷 등 frame 정보 등등을 합쳐 인터넷으로 전송
  • [질문] Socket 라이브러리 외에 네트워크로 데이터를 전송할 수 있는 방법이 있을까?
    - 여러 소켓 라이브러리가 있지만, 소켓이란 용어가 포함되지 않은 다른 라이브러리는 보이지 않음
    - 소켓을 단순 라이브러리가 아닌 표준화된 interface로 보는게 맞는 듯
• 패킷 내용
  • IP 패킷
    - src ip, dest ip, ...
  • TCP 패킷
    - src port, dest port, 전송 제어, 순서, 검증 정보, ...
• TCP 특징
  • Transmission Control Protocol
    - 전송 제어를 한다는 의미
  • 1. 연결 지향
    - TCP 3 way handshake
  • 2. 데이터 전달 보증
  • 3. 순서 보장
  • 신뢰할 수 있는 프로토콜
  • 현재 대부분 TCP를 사용
• 1. 연결 지향: TCP 3 way handshake
  • 클라이언트 -> 서버 : SYN
  • 서버 -> 클라이언트 : SYN+ACK
  • 클라이언트 -> 서버 : ACK
  • 논리적인 연결
    - 중간 노드들은 연결 여부에 관심 없음
    - 클라이언트와 서버도 데이터를 주고 받았으니 연결이 되었다고 생각만 함
    - [질문] *논리적인 연결이기 때문에 "연결되어있다"라는 정의를 확실히 알아야할 듯
• 2. 데이터 전달 보증
  • 데이터를 받은 서버가 잘 받았다는 packet을 전달(ACK)
• 3. 순서 보장
  • 1, 2, 3 순서로 보냈는데 1, 3, 2 순서로 도착
  • 서버에서 2번부터 다시 보내라고 알림
• UDP
  • 기능이 거의 없음(백지)
    - 연결 지향 X
    - 데이터 전달 보증 X
    - 순서 보장 X
  • IP와 거의 같음 (+Port +Checksum)
  • UDP의 장점
    - TCP는 three-way handshake, ACK와 같이 중간 과정이 많아서 느림
    - 최적화가 필요할 경우 UDP로 손을 대면 된다(백지니까)
    - HTTP/3에서 사용하는 등 각광을 받고있다고 함
    - [질문] **그렇다면 HTTP/3의 connection은 어떻게 이루어지는가?

 

• Port
  • IP는 목적지 서버를 찾음
  • Port는 서버 안에서 돌아가는 애플리케이션을 구분
  • 범위 : 0 ~ 65535
    - 잘 알려진 포트 (0~1024)는 사용하지 않는 것이 좋음
    - FTP : 20, 21
    - TELNET : 23
    - HTTP : 80
    - HTTPS : 443

 

• DNS
  • 도메인 네임 시스템(Domain Name Systme)
    - 전화번호부
    - 도메인 명을 IP 주소로 변환
  • DNS 서버에 도메인을 보내면, IP로 돌려줌
    - 기억하기 쉬움
    - IP 변경 문제 해결

 

Appendix

*TCP의 connection

• RFC 793을 찾아봄
• connection이란 단어를 많이 사용하지만, connection에 대한 정의는 찾지 못함
• 3.4 establishing a connection을 살펴봄

• 3.4 Establishing a connection
  • three-way handshake는 connection을 하는 "수단"
  • 즉, three-way handshake가 정상적으로 이루어진 상태를 connection이라 볼 수 있을 것 같음
  • Half-Open connection
    
    • connection이 성립된 후 상대방이 모르는 상태에서 한쪽 TCP가 close되거나 abort된 상태
    • 즉, half-open 상태도 connection으로 간주하는 듯
    • 이러한 문제가 발생했을 경우, RST(reset) segment를 보내 다시 연결 수립을 시작
      - 이 과정에서 RST를 받은 노드는 abort(close)
  • 결론
    - ESTABLISH 이후 CLOSE가 되기 전까지 상태를 connection이라고 보면 되겠다

 **HTTP/3의 connection

• draft문서를 찾아봄
  - https://datatracker.ietf.org/doc/html/draft-ietf-quic-http#section-3

draft-ietf-quic-http-34

• 3. Connection Setup and Management를 읽어봄
  - 3.1 Discovering and HTTP/3 endpoint 내용

HTTP는 신뢰할 수 있는 응답의 개념에 의존합니다. 원본 서버에 의해(또는 원본 서버의 지시에 따라) 응답 메시지가 생성된 시점에 대상 리소스의 상태가 주어졌을 때 해당 요청에 대해 가장 적절한 응답으로 결정된 응답 대상 URI 내에서 식별됩니다. HTTP URI에 대한 권한 있는 서버를 찾는 것은 [의미]의 섹션 4.3에서 논의됩니다.

"https" 체계는 URI의 기관 구성 요소에 의해 식별된 호스트에 대해 클라이언트가 신뢰할 수 있는 것으로 간주하는 인증서의 소유와 기관을 연결합니다. TLS 핸드셰이크에서 서버 인증서를 수신하면 클라이언트는 [SEMANTICS]의 섹션 4.3.4에 설명된 프로세스를 사용하여 인증서가 URI의 원본 서버와 일치하는지 확인해야 합니다. URI의 원본 서버와 관련하여 인증서를 확인할 수 없는 경우 클라이언트는 해당 원본에 대해 서버를 신뢰할 수 있는 것으로 간주해서는 안 됩니다(MUST NOT).

클라이언트는 호스트 식별자를 IP 주소로 해석하고, 표시된 포트에서 해당 주소에 대한 QUIC 연결을 설정하고(위에 설명된 서버 인증서의 유효성 검사 포함) "https" URI가 있는 리소스에 대한 액세스를 시도할 수 있습니다. 해당 보안 연결을 통해 서버에 대한 URI를 대상으로 하는 HTTP/3 요청 메시지입니다. HTTP/3을 선택하는 데 다른 메커니즘이 사용되지 않는 한 TLS 핸드셰이크 동안 ALPN(Application Layer Protocol Negotiation) 확장에서 "h3" 토큰이 사용됩니다.

연결 문제(예: UDP 차단)는 QUIC 연결 설정 실패를 초래할 수 있습니다. 클라이언트는 이 경우에 HTTP의 TCP 기반 버전을 사용하려고 시도해야 합니다(SHOULD).

• 3.2 Connection Establishment도 읽어봄

HTTP/3는 기본 전송으로 QUIC 버전 1에 의존합니다. HTTP/3과 함께 다른 QUIC 전송 버전을 사용하는 것은 향후 사양에서 정의할 수 있습니다(MAY).

QUIC 버전 1은 TLS 버전 1.3 이상을 핸드셰이크 프로토콜로 사용합니다. HTTP/3 클라이언트는 TLS 핸드셰이크 동안 서버에 대상 호스트를 나타내는 메커니즘을 지원해야 합니다(MUST). 서버가 도메인 이름([DNS-TERMS])으로 식별되는 경우 대상 호스트를 나타내는 대체 메커니즘이 사용되지 않는 한 클라이언트는 서버 이름 표시(SNI, [RFC6066]) TLS 확장을 보내야 합니다.

QUIC 연결은 [QUIC-TRANSPORT]에 설명된 대로 설정됩니다. 연결 설정 중에 TLS 핸드셰이크에서 ALPN 토큰 "h3"을 선택하여 HTTP/3 지원이 표시됩니다. 다른 애플리케이션 계층 프로토콜에 대한 지원은 동일한 핸드셰이크에서 제공될 수 있습니다(MAY).

핵심 QUIC 프로토콜과 관련된 연결 수준 옵션은 초기 암호화 핸드셰이크에서 설정되지만 HTTP/3 관련 설정은 SETTINGS 프레임에서 전달됩니다. QUIC 연결이 설정된 후 SETTINGS 프레임(섹션 7.2.4)은 각 엔드포인트에서 해당 HTTP 제어 스트림의 초기 프레임으로 보내야 합니다. 섹션 6.2.1을 참조하십시오.

• 결론
  - 아직 명확하게 이해하지 못했지만, TLS 핸드셰이크와 밀접한 연관이 있는 것으로 보임
  - TLS, ALPN, h3 토큰 등 아직 잘 모르는 내용이므로... 먼저 이 내용에 대한 학습이 필요
  - 이후 QUIC의 connection에 대해 읽어보면 될듯
  https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#section-5

draft-ietf-quic-transport-34