[네트워크] [모든 개발자를 위한 HTTP 웹 기본 지식(김영한)] 1

인터넷 네트워크

IP(인터넷 프로토콜)

IP의 역할

지정한 IP주소에 데이터 전달. 패킷이라는 통신 단위로 전달.

IP 패킷 정보

출발지 IP, 목적지 IP 등 담아서 전달

IP 프로토콜의 한계

• 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성: 중간에 패킷 사라지거나 순서대로 안오면..? (패킷 소실)
• 프로그램 구분: 같은 IP 사용하는 서버에서 통신하는 앱 둘 이상이면?

TCP/UDP

•  IP 패킷 안에 TCP 정보 있다. 
  • 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 -> 이 안에 전송 데이터가 들어 있다.

TCP 특징

• 전송 제어 프로토콜 (Transmission Controal Protocol)
• 연결 지향 - TCP 3 way handshake (가상 연결 - 논리적 연결. 실제로 물리적으로 연결된 건 아님)
  • SYN: 접속 요청
  • ACK: 요청 수락
  • 참고( ACK와 함께 데이터 전송 가능)
  • 서버 꺼져있으면 응답 없네! 연결안되는구나 하고 메시지 안보냄
• 데이터 전달 보증
• 순서 보장 - 서버에서 패킷이 순서대로 안왔으면 다시 보내라고 명령. 중간에서 잘못된 것 부터 다시 보냄
• 신뢰할 수 있고, 현재 대부분 TCP 사용

UDP 특징 

• 사용자 데이터그램 프로토콜 (User Datagram Protocol)
• 기능 없다. 데이터 전달 및 순서 전달 불가. 속도가 빠르다는 장점이 있다.
• IP와 거의 같고, PORT(하나의 애플리케이션에서 여러 일 할때), CHECK SUM 정도만 포함
• HTTP3은 UDP 쓴다.

PORT

• 한번에 둘 이상 연결 필요할 때?
  • 클라이언트가 여러 서버랑 연결해야 함
  • IP만으로 해결 불가 (IP는 목적지 서버 찾는 것). 서버 안에서 구별하는 게 출발지 PORT, 목적지 PORT
  • TCP/IP 합쳐서 부른다.
  • PORT: 같은 IP 내에서 프로세스 구분
    • ex) 게임 서버 연결, 화상통화 통신, 웹 브라우저 요청 
  • IP: 아파트 명 , PORT: 몇 동 몇 호 ?

DNS

• IP는 기억하기 어렵다. 변경될 수도 있음
• DNS: 도메인 네임 시스템. 도메인 명을 IP 주소로 변환
• 1. 도메인 명 google.com
• 2. 응답: DNS서버가 200.200.200.2 알려줌
• 3. 접속: 200.200.200.2 접근

---

URI와 웹 브라우저 요청 흐름

URI(Uniform Resource Identifier)

• URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.
  • URI는 URL(Resource Locator - 리소스가 있는 위치를 지정), URN(Resorce Name- 리소스에 이름을 부여)을 포함하는 관계.
• 단어 뜻
  • Uniform :리소스 식별하는 통일된 방식
  • Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)
  • Identifier: 다른 항목과 구분하는데 필요한 정보
  • 위치는 변할 수 있지만, 이름은 변하지 않는다
  • URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음
  • URI 를 URL과 같은 의미로 설명~
• 리소스를 식별할 수 있다.
• URL 분석
  • https://www.google.com/search?q=hello&hl=ko
  • scheme://[userinfo@]host[:port][/path][?query][#fragment]
    • 주로 프로토콜 사용 (어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 _ http,https,ftp..)
    • 포트: http는 80번 포트, https는 443. 생략 가능 (https는 http에 보안 추가)
    • userinfo: 거의 사용 안함. URL에 사용자 정보 포함헤서 인증
    • 호스트명: 도메인 명 또는 IP주소를 직접 사용 가능
    • 포트: 접속 포트. 일반적으로 사용
    • path: 리소스 경로, 계층적 구조
    • query: key=value 형태. ?로 시작, &로 추가 가능. query parameter, query string 등으로 불림.
      웹서버에서 제공하는 파라미터, 문자 형태
    • fragment: html 내부 북마크 등에 사용. 서버에 전송되는 정보는 아님

웹 브라우저 요청 흐름

1. DNS 조회: IP 뭔지 나옴.

2. HTTP 요청 메시지 생성: GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com

3. 패킷 생성해서 전송 데이터에 2번을 포함해서 인터넷 망으로 던짐.

4. HTTP 응답 메시지를 통해 HTML 보게됨

---

HTTP 기본

모든 것이 HTTP

HTTP 메시지에 모든 것을 전송

HTTP에 거의 모든 것을 담는다.

HTTP 역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
  • RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)]
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

• TCP : HTTP/1.1(주로 사용), HTTP/2
• UDP : HTTP/3

HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능

클라이언트 서버 구조

• Request Response 구조
• 클라이언트는 서버에 요청 보내고 응답 대기. 서버가 요청에 대한 결과 만들어서 응답
• 클라이언트, 서버 분리 하는 게 굉장히 중요.
  • 개념적으로 분리하고 비지니스 로직, 데이터 서버에 집중.
  • 클라이언트는 UI와 관련한거에 집중.
  • 독립적으로 각각 진화 가능. 
  • 복잡한 건 서버에서 처리하도록.

무상태 프로토콜

무상태 프로토콜: 스테이스 리스(Stateless)

• 서버가 클라이언트의 상태를 보존 X
• 장점: 서버 확장성이 높다(스케일 아웃)
• 단점: 클라이언트가 추가 데이터 전송

Stateful, Stateless 차이

• 상태 유지 Stateful: 중간에 점원이 바뀌면?
  • 서버가 클라이언트의 상태 보존.
  • 상태 정보 다른 점원한테 미리 알려줘야 함
  • 항상 같은 서버 유지되어야 한다. 클라이언트가 요청하고 서버가 응답할 때 서버 유지되어야 문제 안생김.
  • 상태 유지: 로그인 - 로그인한 사용자는 로그인했다는 상태 서버에 유지. 브라우저 쿠키, 서버 세션 등 사용.
  • 상태 유지는 최소한만 사용
• 무상태: 중간에 다른 점원으로 바뀌어도 됨.
  • 갑자기 고객 증가해도 다른 점원 투입 가능. 클라이언트 요청 갑자기 증가해도 서버 대거 투입 가능. 
  • 응답 서버 쉽게 바꿀 수 있음 -> 무한 서버 증설 가능
  • 아무 서버나 호출해도 된다.
  • 요청할 때 정보 같이 보내기 때문에 중간에 서버 장애 발생해도 문제 해결 가능
  • 스케일 아웃 - 수평 확장 유리
  • 실무 한계: 모든것을 무상태로 설계 할 수 있을수도, 없을수도
  • 무상태: 로그인 필요없는 단순 서비스 소개

비연결성

특징

• 서버가 계속 연결을 유지하지 않고, 최소한의 자원만 사용. 필요할 때만 연결
• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
  • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다. 
• 서버 자원을 매우 효율적으로 사용할 수 있음

한계와 극복

• TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드
• 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결 - 연결, 종료 낭비를 해결 위해 연결하고 요청 여러개 처리하고 종료
• HTTP/2, HTTP/3에서 더 많은 최적화

스테이스 리스를 기억하자.. 대용량 트래픽 올 때도 대응 가능하도록.

HTTP 메시지

시작 라인

• 요청 메시지
  • start-line = request-line / status-line
  • HTTP 메서드 (GET: 조회)
  • 요청 대상 - 절대 경로 /로 시작
  • HTTP 버전
• 응답 메시지
  • start-line = request-line / status-line
  • HTTP 버전
  • HTTP 상태 코드: 요청 성공, 실패를 나타냄
    • 200: 성공
    • 400: 클라이언트 요청 오류
    • 500: 서버 내부 오류
  • 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글

HTTP 헤더

• header-field = field - name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
• field-name은 대소문자 구분 없음
• 용도
  • 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,
    서버 애플리케이션 정보, 캐시 관리 정보...
  • 표준 헤더가 너무 많음
  • 필요시 임의의 헤더 추가 가능 - helloworld: hooh

HTTP 메시지 바디

• 용도
  • 실제 전송할 데이터
  • HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능