네트워크

황준승·2022년 7월 2일

네트워크

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

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

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

ip 주소 부여

IP 인터넷 프로토콜 역할

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

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

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

IP 프로토콜의 한계

비연결성
- 클라이언트에서 패킷을 받을 대상이 없거나 서비스 불틍상태여도 일단 패킷을 전송한다.
비신뢰성
- 중간에 패킷이 사라질 수도 있다.
  (해당 서버들을 탐색하면서 데이터를 전달하다가 해당 서버가 꺼져버리면??)
- 패킷이 순서대로 오지 않으면??
프로그램 구분
- 같은 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 문법

scheme
- 주로 프로토콜 사용
- 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
  - ex) http, https, ftp 등등
- http는 80포트, https는 443 포트를 주로 사용, 포트는 생략이 가능하다.
- https는 http에 보안 추가 (HTTP Secure)
userInfo
- URL에 사용자 정보를 포함해서 인증
- 거의 사용하지 않음
host
- host 명
- 도메인 명 또는 IP 주소를 직접 사용가능
port
- 포트명(port)
- 접속 포트
- 일반적으로 생략, 생략 시 http는 80, https는 443
path
- 리소스 경로(path), 계층적 구조
- ex)
  - /members
  - /members/100, …
query
- key = value형태
- ? 로 시작, & 로 추가기능
- query parameter, query string 등으로 불림, 웹서버에서 제공하는 파리미터, 문자 형태
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 프로토콜 포함해서…