7 분 소요

Reference

그림으로 배우는 Http & Network Basic, 영진닷컴, 우에노 센 지음


📌 웹은 HTTP로 통신한다

  • 웹 브라우저는 주소 입력란에 지정된 URL에 의지해서 웹 서버로부터 리소스(resource)라고 불리는 파일 등의 정보를 얻고 있다.
    • 클라이언트(client): 서버에 의뢰를 하는 웹 브라우저 등, 요청을 하는 쪽
    • 서버(server): 클라이언트의 요청에 맞는 응답을 내보내주는 쪽
  • HTTP(HyperText Transfer Protocol): 클라이언트에서 서버까지 일련의 흐름을 결정
    • HypterText: 참조(URL, HyperLink)를 통해 한 문서에서 다른 문서로 접근할 수 있는 텍스트
    • Protocol: 규약(약속), 메시지를 주고 받는 양식과 규칙의 체계. 네트워크 기기가 상호간 통신하기 위해서는 서로 같은 방법으로 통신해야 하고, 이런 모든 요소에 필요한 규칙.
  • 즉 웹은 HTTP라 불리는 규약을 통해 통신한다.


📌 HTTP는 어떻게 탄생했나?

  • WWW(World Wide Web, W3): 세계 각지에 있는 연구자들의 지식 공유를 지원하기 위해서 제안되고 탄생했다.
  • W3는 여러 문서를 상호간 관련 짓는 하이퍼텍스트(HyperText)에 의해 서로 참조할 수 있도록 고안되었다.
  • 문서 기술 언어로는 HTML(HyperText Markup Language), 문서 전송 프로토콜로는 HTTP, 문서의 주소를 지정하는 방법은 URL(Uniform Resource Locator) 총 세가지가 제안되었다.
  • 즉 W3는 하이퍼텍스트를 열람할 수 있는 클라이언트 애플리케이션으로 시작하였다. 이것이 현재에는 시스템의 명칭으로 사용되어 흔히 웹(Web)이라 불리고 있다.

HTTP의 역사

  • HTTP/0.9: 1990년 처음 등장한 HTTP, 당시 정식 사양서는 아니었고 정식 사양으로 공개 되기 이전이라는 의미로 0.9로 불리고 있다.
  • HTTP/1.0: 1996년 정식 사양으로 공개된 버전. RFC1945가 발행되었고 아직까지 많은 서버에서 가동되고 있는 프로토콜 사양
    • (RFC1945: HyperText Transfer Protocol, HTTP/1.0)[https://www.ietf.org/rfc/rfc1945.txt]
    • HTTP 헤더 개념이 도입됨
  • HTTP/1.1: 1997년 공개된 버전. 현재 가장 많이 사용되는 버전으로 RFC2068이 발행되었고, 개정판으로 발행된 RFC2616, RFC7230 ~ 7235 가 존재한다.
    • 대부분 HTTP/1.1 을 표준으로 함
    • RFC7230 ~ 7235 문서를 보는 것이 좋음
  • HTTP/2.0: 2015년 공개된 버전. (차세대 HTTP 버전)
    • 기존 HTTP/1.X 버전의 성능 향상에 초점을 맞춘 버전
    • 대체 버전이 아닌 HTTP/1.1의 확장 버전


📌 TCP / IP

  • HTTP를 이해하기 위해서는 TCP / IP 프로토콜을 이해하고 있어야 한다.
    • HTTP는 TCP / IP 프로토콜 중 하나

TCP / IP 의 개념

  • TCP / IP: 인터넷 통신에서 사용되는 프로토콜의 집합으로, TCP와 IP가 결합된 형태로 TCP가 IP 위에서 동작하여 신뢰성 있는 데이터 전송을 보장한다.

    • TCP(Transmission Control Protocol): 데이터 전송 제어 프로토콜로 연결 지향형, 신뢰성 있는 데이터 전송을 담당(패킷 전송 완료 여부와 전송 순서 유지)
      • 패킷 통신은 데이터를 작은 단위로 나누어 전송하기 때문에 데이터가 유실되거나 섞일 수 있다. 이러한 문제를 해결하는 것이 TCP
      • 데이터를 3-웨이 핸드셰이크를 통해 신뢰성 있게 전송하며, 전송 중 데이터가 유실되거나 송신 순서가 바뀌면 재전송 요청(ACK)을 통해 재전송
      • 3-웨이 핸드셰이크: 정확한 전송을 보장하기 위한 사전 과정
        • Client → Server: TCP SYN, 접속 요청
        • Server → Client: TCP SYN ACK, 요청 수락(접속 허가)
        • Client → Server: TCP ACK, 접속 허가 확인
      • 흐름제어(flow control)를 통해 수신측이 처리할 수 있는 양만큼 데이터를 송신하여 버퍼 오버플로우를 방지
    • IP(Internet Protocol): 네트워크 상에서 패킷을 전달하는 역할
      • 패킷 전송 완료 여부나 순서를 보증해주지 않음 → 빨리 전송하는 것이 목적
    • 인터넷의 기본 통신규약이며, 웹, 이메일, 파일전송 등 인터넷에서 이루어지는 모든 통신에 사용

4개의 계층으로 관리되는 TCP / IP

  • 총 4개의 계층(Layer)으로 나뉘어 관리되는 이유
    • 하나의 사양이 변경되었을 때 전체를 바꾸지 않고, 변경된 계층만 바꾸면 된다. (객체 지향의 단일 책임 원칙(SRP)을 생각하면 됨)
    • 계층이 연결되어 있는 부분만 결정되어 있어 내부를 자유롭게 설계할 수 있다.
    • 단일 책임 원칙, 각 계층은 자기 자신이 담당하는 부분만 고려하면 된다. → 설계가 편해짐

애플리케이션 계층 (Application Layer)

  • 4 계층이라 불리며 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정(유저와 가장 가까운 계층)
    • 애플리케이션 실행을 위한 데이터 형식이 작성되는 계층
    • 여러 가지의 공통 애플리케이션이 존재
      • ex: FTP, DNS, SSH 등
    • HTTP(HTTPS) 도 애플리케이션 계층에 포함

트랜스포트 계층 (Transport Layer)

  • 애플리케이션 계층에 접속되어 있는 통신 노드 사이의 데이터 흐름을 제공한다. 즉, 통신 노드 간 신뢰성 있는 데이터 전송을 보장하는 계층
  • Port 번호를 통해 데이터를 목적지의 애플리케이션에 전달
  • 서로 다른 성질을 가진 TCP, UDP 가 대표적으로 존재한다.
    • UDP(User Data Protocol): 신뢰성이 보장되지 않는 빠른 데이터 전송이 필요한 경우 사용되는 프로토콜
      • TCP와 달리 연결 지향형이 아닌 비연결 지향형이므로 패킷 전송 완료 여부나 순서 보증을 하지 않는다.
      • 무상실 데이터(VoIP, 실시간 게임) 전송에 적합하다.
      • 헤더 사이즈가 작고 처리 속도가 빠르다.
      • IP 주소 + Port 번호로 구성된다.

네트워크 계층 (Network Layer, Internet Layer)

  • 네트워크 상에서 패킷의 이동을 다루는 계층, 어떠한 경로(절차)를 거쳐 상대방에게 패킷을 보낼지를 결정. (패킷의 네비게이션 역할)
    • 패킷(Packet): 전송하는 데이터의 최소 단위
    • 패킷을 목적지 까지 전달하는 여러 가지 선택지 중 하나의 선택을 결정하는 역할
    • IP, ARP, ICMP 등이 프로토콜로 사용됨
  • 네트워크에 접속하는 하드웨어적인 측면을 다루는 계층
    • OS가 하드웨어를 제어하기 때문에 디바이스 드라이버, 네트워크 인터페이스 카드(NIC)를 포함
  • 케이블 등과 같은 물리적으로 보이는 부분(여러 전송 매체)도 포함하는 계층
  • 하드웨어적 측면은 모두 데이터 링크 계층의 역할
  • 즉, 실질적으로 데이터를 전송하는 계층

TCP / IP 통신의 흐름

TCP / IP 통신의 흐름은 계층을 순서대로 거쳐 상대와 통신을 한다.

  • 송신측: 애플리케이션 계층에서부터 내려감
  • 수신측: 애플리케이션 계층으로 올라감

HTTP 통신의 예제

  1. 송신측 클라이언트의 애플리케이션 계층에서 어느 웹 페이지를 보고 싶다는 요청(HTTP Message)을 HTTP Request로 지시한다.
  2. 송신측 트랜스포트 계층에서 애플리케이션 계층에게 받은 요청(HTTP Message)을 통신하기 쉽게 조각내어(패킷) 안내 번호와 포트 번호를 붙여 네트워크 계층에 전달한다.
  3. 송신측 네트워크 계층에서 수신지 MAC 주소를 추가해 링크 계층에 전달
  4. 링크 계층에서 네트워크를 통해 송신할 준비를 하고, 수신측 네트워크에 송신
  5. 수신측 서버는 링크 계층에서 데이터를 받아 순서대로 위 계층에 전달하여 클라이언트가 보낸 HTTP Rquest 내용을 서버의 애플리케이션 계층으로 보낸다.
  6. 수신측 서버가 송신측의 역할이 되어 위 과정을 통해 수신측이 된 클라이언트 에게 리소스를 전송한다.
  • HTTP 통신에서 송신측은 각 계층을 거칠 때마다 헤더와 필요한 데이터가 추가되고(캡슐화), 수신측은 각 계층을 거칠 때마다 해당 계층에서 사용한 헤더를 삭제(역 캡슐화)한다.
  • HTTP Message: 서버와 클라이언트 간 데이터가 교환되는 방식.
    • 요청: 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지
    • 응답: 요청에 대한 서버의 답변


📌 HTTP와 관계가 깊은 프로토콜

IP (Internet Protocol)

  • 네트워크 계층에 해당되는 프로토콜
  • 인터넷을 활용하는 거의 대부분의 시스템이 이용
  • IP의 역할은 각각의 패킷을 상대방에게 전달하는 역할, 상대방에게 패킷을 전달하기 위해 필요한 요소들 중 IP 주소와 MAC(Media Access Control)주소가 중요한 역할을 한다.
    • ‘IP’ 와 ‘IP 주소’를 혼동하지 말자
    • IP 주소: 각 노드에 부여된 주소, 변경 가능
    • MAC 주소: 각 네트워크 카드에 할당된 고유의 주소, 변경 불가능

통신은 ARP를 이용해 MAC 주소에서 한다

  • IP 통신은 MAC 주소에 의존해서 통신을 한다.
  • 인터넷은 여러 대의 컴퓨터와 네트워크 기기를 중계해서 상대방에게 도착하게 한다. 인터넷이 중계하는 동안에는 다음으로 중계할 곳의 MAC 주소를 사용해 목적지를 찾고, 이때 사용하는 프로토콜이 ARP(Address Resolution Protocol)
    • ARP: 주소를 해결하기 위한 프로토콜, 수신지의 IP 주소를 바탕으로 MAC 주소를 조사
  • 목적지까지 중계를 하는 도중 네트워크 기기(컴퓨터, 라우터)는 목적지에 도착하기까지 대략적인 목적지만을 알고 있다. 즉, 어떤 컴퓨터나 네트워크 기기도 인터넷 전체를 상세히 파악하고 있지는 않다.
    • 이 시스템을 라우팅이라 한다.
    • 택배 시스템과 비슷하다. 보내는 사람이 주소를 적어 보내면, 허브는 지역 허브 까지, 지역 허브는 배송 집배소 까지, 집배소는 목적지집만 알고 있으면 된다.

TCP (Transmission control Protocol)

  • 트랜스포트 계층에 해당하는 프로토콜, 신뢰성 있는 바이트 스트림 서비스를 제공하는 역할

    • 바이트 스트림: 큰 데이터를 보내게 쉽게 TCP 세그먼트라고 불리는 단위 패킷으로 작게 분해하여 관리하는 것
    • 신뢰성 있는 서비스: 정보가 목적지에 잘 도착했는지 확인(보증)

  • 즉, TCP는 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대방에게 보내고, 잘 도착했는지 확인하는 역할을 한다.

  • 신뢰성 있는 서비스를 제공하기 위해 3-way handshaking 을 사용한다. (SYN, ACK 라는 TCP 플래그를 사용)

    1. 송신측이 최초 SYN 플래그로 상대에게 접속함과 동시에 패킷을 보냄
    2. 수신측이 SYN/ACK 플래그로 송신측에 접속함과 동시에 패킷을 수신한 사실을 보냄
    3. 송신측이 ACK 플래그를 보내 패킷 교환이 완료되었음을 보냄
    • 과정 중 패킷이 손실되거나 통신이 끊어지면 TCP는 다시 같은 순서로 패킷을 재전송한다.

DNS (Domain Name System)

  • 애플리케이션 계층에서 도메인 이름과 IP 주소 이름 확인을 제공하는 역할
  • 컴퓨터는 IP 주소와는 별도로 호스트 이름과 도메인 이름을 붙일 수 있는데 주로 사용자는 IP 주소 대신 이름을 이용해 상대의 컴퓨터를 지정한다.
  • 사용자와 반대로 컴퓨터는 IP 주소를 선호한다. 이런 반대되는 문제를 해결하기 위해 DNS가 존재한다.
    • DNS는 도메인명을 바탕으로 IP 주소를 조사하고, IP 주소를 바탕으로 도메인명을 조사한다.

HTTP를 이용한 통신 과정

  1. 클라이언트(송신측)가 DNS 에게 도메인명을 알려주고 IP 주소를 요청한다.
  2. DNS가 요청된 도메인명의 IP 주소를 클라이언트에게 응답한다.
  3. HTTP 담당 웹 서버에 보낼 HTTP 메시지를 작성한다. (ex: www.google.com의 리소스를 알려줘)
  4. TCP가 통신하기 쉽도록 HTTP 메시지를 패킷으로 분해해 상대방에게 패킷을 보낸다.
  5. IP 가 목적지에 보내기 위해 라우팅 과정을 진행한다.
  6. 목적지에 패킷들이 도착하고, 목적지의 TCP가 도착한 패킷들을 조립한다. (이때, 일려번호를 보고 패킷을 조립)
  7. HTTP 가 웹 서버에 대한 요청 내용을 처리한다.
  8. 처리한 결과를 마찬가지로 위 과정을 반복해 순차적으로 클라이언트에게 반환한다.


📌 URI & URL

URL은 URI의 subset(부분집합)

  • URL(Uniform Resource Locator): 웹 브라우저 등에서 웹 페이지를 표시하기 위해 입력하는 주소
    • ex: https://www.google.com
  • URI(Uniform Resource Identifiers): 리소스를 식별하는 통합 자원 식별자
    • Uniform: 통일된 서식을 결정하는 것으로, 여러 종류의 리소스 지정 방법을 같은 맥락에서 구별없이 취급할 수 있게 한다. 또 새로운 스키마 도입을 용이하게 한다.
      • 스키마: http:, ftp 등과 같은 네트워크 연결 방법에 이름을 붙인 것
    • Resource: 식별 가능한 모든 것, 문서 파일뿐만 아니라 이미지, 서비스등 다른 것과 구별할 수 있는 모든 것을 의미함. (RFC2396)
    • Identifier: 식별 가능한 것을 참조하는 오브젝트. (RFC2396)
  • URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자
  • URI는 리소스를 식별하기 위해 문자열 전반을 나타내고, URL은 리소스의 장소(네트워크 상 위치)를 나타낸다.

URL(URI) 포맷

  • 절대 URL(URI): 필요한 정보 전체를 지정하는 완전 수식

    http://user:pass@www.google.com:80/dir/index.htm?uid=1#ch1
    • http://: 스키마, 리소스를 얻기 위해 사용하는 프로토콜을 지시
    • user:pass: 자격정보(credential), 서버로부터 리소스를 취득하기 위해 필요한 정보. 유저명과 패스워드를 지정할 수 있고 옵션임.
    • www.google.com: 서버주소, DNS 이름(www.google.com)이나 192.0.12.34 와 같은 IPv4 주소나 IPv6 주소를 대괄호로 묶어서 지정.
    • 80: 서버 포트, 서버의 접속 대상이 되는 네트워크 포트 번호, 옵션이며 생략 하면 default port가 사용됨.
    • dir/index.htm: 계층적 파일 패스, 특정 리소스를 식별하기 위해 서버 상의 파일 패스를 지정
    • ?uid=1: 쿼리, 파일 패스로 지정된 리소스에 파라미터를 넘겨주기 위해 사용
    • ch1: 프래그먼트 식별자, 취득한 리소스에서 서브 리스트를 가리키기 위해서 사용

  • 상대 URL(URI): 현재 작성하는 문서를 기준으로 리소스의 경로를 지정

댓글남기기

참고

[프로그래밍] 좋은 테스트 코드 작성하기

6 분 소요

References Testing, Oh my! 스프링 캠프 2019: 무엇을 테스트할 것인가? 어떻게 테스트할 것인가? [번역글] UnitTest By Martin Fowler 3월 우아한테크세미나: 우아한 ATDD

[자바] final 키워드 & 불변 객체

2 분 소요

References [10분 테코톡]시카의 Java final과 불변 객체) 불변 객체(Immutable Object) 및 final을 사용해야 하는 이유 - Mangkyu님 블로그

[자바] Java Enum

2 분 소요

References Java Enum 활용기 - 우아한 기술 블로그