배움을 기록으로

3. HTTP 기본

3.1. 모든 것이 HTTP

'HTTP 메시지에 모든 것을 전송'

• HTML, TEXT
• IMAGE, 음성, 영상, 파일 등
• JSON, XML
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
• HTTP/1.1이 현재 가장 많이 사용하는 버전이며, 그 이후 버전은 성능 개선 위주

[ 기반 프로토콜 ]

• TCP : HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용 (HTTP/2, HTTP/3 도 점점 증가)

[ HTTP 특징 ]

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

3.2. 클라이언트 서버 구조

'Request Response 구조'

• Request Response 구조 (클라이언트와 서버를 개념적으로 분리)
• 클라이언트는 UI와 사용성, 서버는 복잡한 비지니스 로직 및 데이터를 전담 (역할 분리 > 독립적 진화 가능)
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

3.3. Stateful, Stateless

'HTTP는 무상태 프로토콜을 지향한다 (Stateless)'

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 장점: 서버 확장성 높음 (스케일 아웃 > 수평 확장 유리)
• 단점: 클라이언트가 추가 데이터 전송 (필요한 데이터를 모두 넘겨야 하기 때문)
• 실무 한계
  • 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
    • 상태 유지: 로그인이 필요한 화면
      • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
      • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지 (무상태에서 로그인 상태 유지하는 방법)
      • 상태 유지는 최소한만 사용
    • 무상태: 로그인이 필요 없는 단순한 서비스 소개 화면
• 결론: 애플리케이션 설계시에는 최대한 무상태로 설계하고, 상태 유지는 최소한만 사용한다.

[ Stateful, Stateless ]

• 상태 유지: 중간에 다른 서버로 바뀌면 안된다.
                  (다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.)
  • 중간에 서버가 장애나면? 클라이언트는 처음부터 다시 요청을 해야한다.
    
    
• 무상태: 클라이언트의 상태를 보존하지 않으므로, 중간에 다른 서버로 응답할 수 있다.
  
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다.
  • 중간에 서버1이 장애나면? 서버2가 응답하면 된다.
    
    

3.4. 비 연결성 (connectionless)

'비 연결성이란?'

• 연결을 유지하지 않는 모델이다.
• HTTP는 일반적으로 초 단위의 이하의 빠른 속도로 응답 (요청할 때마다 연결하여 사용 가능, 요청이 끝난 후에는 연결 종료)
• 1시간 동안 수천명이 서비를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
  • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
• 서버의 자원을 매우 효율적으로 사용할 수 있다. (최소한의 자원 사용하여 서버 유지 가능)
• 한계와 극복
  • TCP/IP 연결을 새로 맺어야 함 (3 way handshake 시간 추가)
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS,CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
    (연결만 상태 유지하여, 매 요청시 연결을 새로 하지 않도록)
  • HTTP/2, HTTP/3에서 더 많은 최적화
• 대용량 트래픽 설계시에는 Stateless를 꼭 기억하자
  • 같은 시간에 발생하는 대용량 트래픽
  • 이벤트가 생길때 사용자가 급증하는 경우
  • 팁: 정적 페이지를 하나 보게 한 다음, 이벤트 페이지로 들어가게 만드는 방법 (최대한 동시 요청을 적게)
    
    

3.5. HTTP 메시지

'HTTP 메시지 구조'

[ 예시 ]

• 요청 메시지

• 응답 메시지

3.6. HTTP 정리

'지금은 HTTP 시대'

• HTTP 메시지에 모든 것을 전송
• HTTP 역사 HTTP/1.1을 기준으로 학습
• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스)
• HTTP 메시지
• 단순함, 확장 가능
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술 (HTTP 메시지도 매우 단순)
  
  

References

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

2. URI와 웹 브라우저 요청 흐름

2.1. URL (Uniform Resource Identifier)

'URI? URL? URN?'

• URI와 URL이 혼동되기 쉽다. 결론부터 말하자면 URI는 URL와 URN의 상위 개념이다.

[ URI 단어 뜻 ]

• Uniform: 리소스 식별하는 통일된 방식
• Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)
• Identifier: 다른 항목과 구분하는데 필요한 정보

[ URL, URN ]

• URL - Locator: 리소스가 있는 위치를 지정
• URN - Name: 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• 통상적으로 URI와 URL을 같은 의미로 사용하기도 한다.

[ URL 문법 ]

https://www.google.com:443/search?q=hello&hl=ko 

• 프로토콜 (https)
• 호스트명 (www.google.com)
• 포트 번호 (443, 생략가능)
• 패스 (/search)
• 쿼리 파라미터 (q=hello&hl=ko)

2.2. 웹 브라우저 요청 흐름

'브라우저에 검색창에 'www.google.com'을 입력하면 일어나는일'

1.  'www.google.com'에 대한 DNS 서버를 조회
   • IP와 PORT 정보를 얻는다
   • 캐싱된 DNS 기록을 체크
2.  웹 브라우저가 HTTP 요청 메시지를 생성
3.  SOKET 라이브러리를 통해 OS 단으로 HTTP 메시지를 전달한다.
   • TCP/IP 연결 (구글 서버와 연결 상태 확인)
   • 데이터 전달 (OS 단으로)
4.  TCP/IP 패킷 생성, HTTP 메시지 포함
5.  웹 브라우저에서 요청 패킷을 구글 서버에 전달 / 도착
6.  구글 서버에서 HTTP 요청 메시지에 대한 HTTP 응답 메시지 생성
7.  구글 서버에서 응답 패킷을 웹 브라우저에 전달 / 도착
8.  받은 응답 패킷을 기준으로 웹 브라우저에 HTML 렌더링

References

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

실무에서 백엔드 개발을 진행하면서, 네트워크/인프라 등 배경지식이 부족하다고 느껴져서

네트워크 기초에 대한 부분을 공부하기로 하였다.

실무 개발에 필요한 HTTP의 전체 흐름 이해하기 위한 포스팅이며

'모든 개발자를 위한 HTTP 웹 기본 지식' 강의를 학습한 내용을 정리할 생각이다.

1.인터넷 네트워크

1.1. 인터넷 통신

'인터넷 상에서 컴퓨터 둘은 어떻게 통신할까?'

•  직접 연결 (클라이언트와 서버, 둘 사이가 가까운 경우), 하지만 한계가 있다. 사내망 같은 사설망에서만 사용
•  인터넷망 이용(거리가 멀어도 통신 가능)하며, 인터넷망은 IP를 사용하여 통신한다.

1.2. IP(인터넷 프로토콜)

'복잡한 인터넷망은 어떻게 통신을 할까?'

•  클라이언트와 서버에 IP 주소를 부여 (출발지와 목적지에 대한 주소)
•  IP 주소에 데이터 전달
•  패킷이라는 통신 단위로 데이터 전달

[ IP ]

•  인터넷 프로토콜 (Internet Protocol)의 약자
•  네트워크상에서 컴퓨터(노드)를 식별하기 위한 위치 주소
•  한계 및 문제점
  • 비연결성: 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷 전송
  • 비신뢰성: 중간에 패킷이 오거나, 순서대로 안 오는 경우 신뢰할 수 없다.
  • 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 2개 이상인 경우 구별 불가
• 해당 한계들을 극복하고자, TCP/UDP가 등장하기 시작했다.

[ IP 패킷 ]

• 정보 : 출발지 IP, 목적지 IP, 기타
• 출발지 IP에서 목적지 IP로 요청을 클라이언트 패킷에 담아 전달한다.
• 목적지 IP에서 요청에 대한 응답을 서버 패킷에 담아 전달한다.

1.3. TCP/UDP

'IP만으로 통신할 때의 한계나 문제점을 어떻게 해결해야 할까?'

• 비연결성 : 통신 전에 클라이언트와 서버의 연결 상태 및 데이터 전달 보증 확인
• 비신뢰성 : 패킷에 데이터의 순서 정보를 함께 보낸다
• 프로그램 구분 : 프로그램별 구분 값(PORT)을 이용

[ 인터넷 프로토콜 스택의 4계층 ]

• 애플리케이션 계층 - HTTP, FTP
• 전송계층 - TCP, UDP
• 인터넷 계층 - IP
• 네트워크 인터페이스 계층

[ TCP (Transmission Control Protocl) 특징 ]

• 연결지향 - TCP 3 way handshake (가상 연결, 논리적 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

[ TCP 3 way handshake ]

1. SYN : 클라이언트 > 서버 (접속 요청)
2. SYN+ACK : 서버 > 클라이언트 (연결 요청 수락)
3. ACK: 클라이언트 > 서버 (연결 요청 수락에 대한 응답)
4. 데이터 전송 (참고: 요즘에는 최적화로 인해 ACK와 함께 데이터 전송도 가능)

[ UDP (User Datagram Protocol) ]

• 연결지향 X
• 데이터 전달 보증 X
• 순서 보장 X
• IP와 거의 같다. +PORT +체크섬 정도만 추가
• 애플리케이션에서 추가 작업 필요

UDP는 왜 쓰는걸까?

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• TCP에 비해 보안적으로 덜 안전하지만, 많은 양의 데이터를 빠르게 전달 가능 (영상 스트리밍이나 음성에 활용)
• 최근 인터넷이 거의 TCP 기반으로 되어있기 때문에, TCP를 수정하기가 어려움 
• 그래서 최적화를 위한 수정 개발시에는 UDP를 활용, 최근에는 UDP가 뜨고 있다고함 (ex: HTTP 프로토콜)

1.4. PORT

'한 번에 둘 이상 연결해야 한다면 어떻게 해야할까?'

[ PORT 특징 ]

• 같은 IP 내에서 프로그램(프로세스)를 구분
• 0 ~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

1.5. DNS

'IP는 기억하기 어렵고, 변경될 수 있다.'

•  도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환
  
  

References

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