네트워크

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

• 복잡한 인터넷 망으로 연결되어 있다.
• 수많은 중간 노드(서버)들을 거쳐서 메세지를 전송하고 있다.

과연 어떠한 규칙으로 서버끼리 메세지를 전송할까?

• ip 주소 부여

IP 인터넷 프로토콜 역할

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달
• IP 패킷 정보

IP 프로토콜을 통한 패킷 통신

• 클라이언트에서 출발지와 목적지가 담긴 IP 패킷데이터를 전송
• 인터넷 망에서 목적지에 해당하는 서버를 찾는다.
• 요청한 서버 ip주소에 제대로 도착했다면 해당 서버는 클라이언트에게 도착했다는 정보를 다시 전송한다.
• 이때, 출발지와 목적지는 반대로 된다.

IP 프로토콜의 한계

1. 비연결성

   • 클라이언트에서 패킷을 받을 대상이 없거나 서비스 불틍상태여도 일단 패킷을 전송한다.

2. 비신뢰성

   • 중간에 패킷이 사라질 수도 있다.
     (해당 서버들을 탐색하면서 데이터를 전달하다가 해당 서버가 꺼져버리면??)
   • 패킷이 순서대로 오지 않으면??

3. 프로그램 구분

   • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면??

• 하나의 두 컴퓨터가 데이터 송수신을 하기 위한 소켓 프로그램(채팅 앱)이 있다고 가정해보자.
• 어플리케이션을 통해서 Hello, world! 라는 메시지를 생성하고 socket 라이브러리를 통해서 메시지가 전달된다.
• 그 다음 TCP 프로토콜에 의해서 패킷에 TCP 정보를 추가로 넣고
• 그 다음 IP 프로토콜에 의해서 패킷에 IP 정보를 추가적으로 넣습니다.
• 그리고 네트워크 인터페이스에 의해 Ethernet frame( ex) 우리의 MAC 주소와 이더넷 주소 등을 포함한 정보) 들을 추가적으로 넣고 서버에 보냅니다.

TCP 특징

• 전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake (가상 연결)

  • 내가 전송하고자 하는 서버가 실제로 존재하는지 논리적으로 확인한다.
  • 인터넷 망에 있는 수많은 노드 서버들을 이를 알 수 없다.

• 데이터 전달 보증

• 순서 보장

• 신뢰할 수 있는 프로토콜

• 현재는 대부분 TCP를 사용하고 있다.

---

• 클라이언트가 실제로 서버가 존재하는지 확인하기 위해 SYN 데이터를 보낸다.
• 서버가 SYN데이터를 받으면 요쳥수락하는 ACK 데이터를 보내고 마찬가지로 서버도 접속 요청하는 SYN 데이터를 보낸다.
• 그리고 클라이언트가 서버에서 보낸 SYN 데이터에 대한 응답 데이터(ACK)를 다시 보냄으로써 가상 연결이 완료된다. (논리적인 연결)

UDP 특징

• 사용자 데이터그램 프로토콜(User Datagram Protocol)
• 하얀 도화지에 비유(기능이 거의 없음)
• 연결지향 - TCP 3 way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• 정리
  • IP와 거의 같다. +PORT, + 체크섬 정도만 추가
    • PORT : 어떤 어플리케이션의 차이인지
    • 체크섬 : 해당 데이터 신뢰성 여부 판단
  • 애플리케이션에서 추가 작업 필요

---

PORT

• IP : 서버를 구분시켜주는 주소

• PORT : 서버 안에 어플리케이션을 구분시켜주는 주소

  • 같은 IP 내에서 프로세스 구분

• 0 ~ 65535 : 할당 가능

• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음

  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

DNS

• ip 주소의 두 가지 문제점을 해결하기 위해 만들어졌다.

  1. IP는 기억하기 어렵다.
  2. IP는 변경될 수 있다.

• 도메인 네임 시스템(Domain Name System)

• 전화번호부

• 도메인 명을 IP 주소로 변환

---

URI

• URI는 Uniform Resource Identifier, 통합 자원 식별자의 줄임말이다.
• URI는 인터넷의 자원을 식별할 수 있는 문자열을 의미한다.
• 하위 개념으로 URL과 URN이 있다.
  • URL(Uniform Resource Identifier) : 리소스가 있는 위치를 지정
  • URN(Uniform Resource Name) : 리소스에 이름을 부여 → 보편화 X
  • 위치는 변할 수 있지만, 이름은 변하지 않는다.

URL 문법

1. scheme

   • 주로 프로토콜 사용
   • 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
     • ex) http, https, ftp 등등
   • http는 80포트, https는 443 포트를 주로 사용, 포트는 생략이 가능하다.
   • https는 http에 보안 추가 (HTTP Secure)

2. userInfo

   • URL에 사용자 정보를 포함해서 인증
   • 거의 사용하지 않음

3. host

   • host 명
   • 도메인 명 또는 IP 주소를 직접 사용가능

4. port

   • 포트명(port)
   • 접속 포트
   • 일반적으로 생략, 생략 시 http는 80, https는 443

5. path

   • 리소스 경로(path), 계층적 구조
   • ex)
     • /members
     • /members/100, …

6. query

   • key = value형태
   • ? 로 시작, & 로 추가기능
   • query parameter, query string 등으로 불림, 웹서버에서 제공하는 파리미터, 문자 형태

7. fragment

   • html 내부 북마크 등에 사용(스크롤 위치 등을 알려고 할 때)
   • 서버에 전송하는 정보가 아님
   • 주석 같은 느낌
   • 해시 뱅 : https://blog.outsider.ne.kr/698

웹 브라우저 요청 흐름

• 웹 브라우저에서 해당 url로 자원을 요청한다면 위와 같은 HTTP 메시지를 만들어 구글 서버에 전송한다.
• 이렇게 구글 서버에 도착한 패킷은 해당 쿼리에 대한 데이터를 받아 그에 해당하는 내용(데이터 or html 등등)을 받아서 다시 클라이언트에게 전송한다.

---

HTTP

• HTTP 메시지에 모든 것을 전송
• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML(API)
• 거의 모든 형태의 데이터 전송 가능
• 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용

---

HTTP 역사

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

---

기반 프로토콜

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

---

HTTP 특징

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

---

HTTP 클라이언트 서버 구조

• Request Response 구조 → 이때 클라이언트와 서버를 나누면 서로가 독립적으로 성장할 수 있다. → 클라이언트는 사용자 UI, UX에 집중하고 서버는 비지니스 로직과 데이터 처리에 좀 더 집중할 수 있다.
  
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

---

무상태 프로토콜(stateless)

Stateful, Stateless 차이

→ 상태 유지 : 중간에 다른 점원으로 바뀌면 안된다.

• 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야함

→ 무상태 : 중간에 다른 점원으로 바뀌어도 된다.

• 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
• 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

---

Stateless 실무 한계

• 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.

• 무상태

  • ex) 로그인이 필요 없는 단순한 서비스 소개 화면

• 상태 유지

  • ex) 로그인

• 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지

• 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지

• 상태 유지는 최소한만 사용

• 단점 : 클라이언트에서 요구되어지는 많은 데이터를 서버에 보내야 한다…..
  

---

HTTP 비연결성

• 연결성 - 클라이언트가 요청하고 서버는 해당 응답이 완료한 이후에도 해당 클라이언트와의 연결을 계속 유지하는 상황
• 비연결성 - 클라이언트가 요청하고 서버는 해당 응답이 완료했으면 그 즉시 연결을 끊어버리는 상황

장점

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

단점

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

---

HTTP 메세지 구조

Starte-line(시작라인)

• start-line = request-line / status-line

• request-line = method request-target HTTP-version

• method : 서버가 수행해야할 동작

• request-target

  • 보통 url의 path를 의미

• HTTP-version

• status-line = HTTP-version status-code reason-phrase

• status-code

  • HTTP 상태 코드 - 연결이 되었는지 안되었는지 상태들을 나타냄

• reson-phrase

  • HTTP 상태 코드를 간략하게 설명하는 구문

HTTP 헤더

• header-field = field-name: field-value
  

• HTTP 전송에 필요한 모든 부가정보
• ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 어플리케이션 정보, 캐시 관리 정보 등등

HTTP 메시지 바디

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

HTTP 메시지

장점 : 단순하고 확장성이 좋다.

---

표현 헤더(Representation Header)

• HTTP 바디에서는 데이터 메시지 분문(Message body)를 통해 표현 데이터를 전달합니다.
• 여기서 데이터를 실어나르는 부분을 페이로드(Payload)라 합니다.
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더 : 표현데이터를 해석할 수 있는 정보 제공
  • ex) 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

표현 헤더 유형

• Content-Type : 표현 데이터의 형식

• Content-Encoding : 표현 데이터의 압축 방식

• Content-Language : 표현 데이터의 자연 언어

• Content-Length : 표현 데이터의 길이

• 표현 헤더는 전송, 응답 둘 다 사용

Content-Type

• 표현데이터에 들어가는 내용 타입이 뭔지 설명
• 미디어 타입, 문자 인코딩
• ex) text/html; charset=utf-8 , application/json , image/png

Content-Encoding

• 표현 데이터를 압축하기 위해 사용
• 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
• 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
• ex) gzip , deflate , identity

Content-Language

• 표현 데이터의 자연 언어
• ex) ko , en , en-US

Content-Length

• 바이트 단위
• Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

---

협상(컨텐츠 네고시에이션)

• 클라이언트가 선호하는 표현 요청(클라이언트 요청 시에만 사용)
• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

예시

협상과 우선순위 - 1 -

• Qualilty Values(q) 값을 사용
• 0 - 1, 클수록 높은 우선순위
• 생략하면 1
• ex)
  • 1.ko-KR;q=1 (q 생략 가능)
  • 2.ko;q=0.9
  • 3.en-US;q=0.8
  • 4.en;q=0.7

---

• TCP 7계층 공부하기

  OSI 7계층은 우리 통신도 데이터 흐름을 파악하기 쉽게 계층을 나눠놨고 계층 하나 하나가 모듈화 되어 있습니다. 각 계층은 독립적이며 확장성에 용이하다.

  물리계층

  • 0 ~ 1의 나열을 아날로그 신호로 바꾸어 전선으로 흘려 보내고(encoding)
  • 아날로그 신호가 들어오면 0과 1의 나열로 해석한다. (decoding)
  • 물리적으로 연결된 두 대의 컴퓨터가 0과 1의 나열을 주고 받을 수 있게 해주는 모듈(module)
    

  

  ( 여러 대의 컴퓨터의 통신 )

  • 컴퓨터가 서로 통신하기 위해서는 컴퓨터들끼리 수많은 선으로 연결되어야 한다.

  • 더미 허브라고 하는 상자에 여러 개의 컴퓨터를 연결하면 데이터를 서로 교환할 수 있다.

    • (but 상자에 연결되어 있는 모든 컴퓨터에게 데이터가 공유된다.)

  • 스위치 : 메세지의 목적지를 확인하여 원하는 컴퓨터에게만 메세지 전송 가능

  • 라우터 : 서로 다른 네트워크에 속한 컴퓨터끼리 통신이 가능하게 해주는 장비

    

  • 인터넷 : 이렇게 전 세계의 컴퓨터들을 연결한 것

    

    데이터 링크 계층

  • 만약 나의 컴퓨터에게 여러 컴퓨터가 보낸 메시지들의 들어왔다고 한다면 각 컴퓨터들에게 들어온 메세지를 구분지을 필요가 있다.

  • 따라서 송신자는 데이터의 앞 뒤에 특정한 비트열을 붙입니다.

    

  • 같은 네트워크에 있는 여러 대의 컴퓨터들이 데이터를 주고 받기 위해서 필요한 모듈

  • Framing은 Date-link Layer에 속하는 작업들 중 하나.

    

  • 랜카드에서 구현

    네트워크 계층

  • 수많은 네트워크들의 연결로 이루어지는 inter-network 속에서

  • 어딘가에 있는 목적지 컴퓨터로 데이터를 전송하기 위해

  • IP 주소를 이용해서 길을 찾고 (routing)

  • 자신 다음의 라우터에게 데이터를 넘겨주는 것(fowording) - fowarding table로..

    

    Transport Layer

  • Port 번호를 사용하여 (하나)

    • Port 번호 : 하나의 컴퓨터(동일한 ip)에서 동시에 실행되고 있는 프로세스들이 서로 겹치지 않게 가져야하는 정수값(서버에서 동시에 실행되고 있는 프로세스들을 구분짓기 위해서)

  • 도착지 컴퓨터의 최종 도착지인 프로세스에까지

  • 데이터가 도달하게 하는 모듈

    

    • data link Layer 생략

  • 사실 현대의 인터넷은 OSI 모델이 아니라 TCP/IP 모델을 따르고 있습니다.

    

  • http 프로토콜 포함해서…