Network Summary
1.OSI 7계층
(Open System Interconnection Reference Model)
국제표준화기구 에서 개발한 모델. 통신 접속에서 완료까지의 과정을 7단계로 표현
7계층으로 나눈 이유
계층을 나눈 이유는 통신이 일어나는 과정이 단계별로 파악할 수 있기 때문이다.
흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽고,
7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들이지 않고도 이상이 생긴 단계만 고칠 수 있기 때문이다.
(1) 물리(Physical)
데이터를 전기적인 신호로 변환해서 주고받는 기능을 진행한다
이 계층에서는 주로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하게 된다.
이 계층에서 사용되는 통신 단위는 비트이며 이것은 1과 0으로 나타내어지는, 즉 전기적으로 On, Off 상태라고 생각하면 된다.
(ex : 리피터, 케이블, 허브)
(2) 데이터 링크(Data Link)
네트워크 기기 간 데이터 전송, 오류 검출 및 제어, 그리고 흐름 제어 등을 담당
대표적인 프로토콜 : Ethernet(이더넷) 프로토콜
Mac 주소를 통해 통신
제 1계층만 있다면, 원하는 목적지로 전송이 불가능 하기에 모든 곳에 동시 전송한다던지 등의 비효율이 발생 한다.
데이터 링크 계층은 신호를 올바른 목적지까지 전달하고, 전송 중 발생할 수 있는 오류를 검출 및 수정하며, 흐름제어를 수행한다.
(ex : 스위치, 브릿지)
(3) 네트워크(Network)
다양하고 방대한 네트워크 상에서, 컴퓨터간 논리적 연결을 위해 네트워크 계층 필요
라우터를 통해 이동할 경로를 선택해 IP주소를 지정하고, 경로따라 패킷 전달
- 상대방이 제대로 받았는지에 대해서는 보장하지 않는 비연결형적인 특징을 가지고 있다.
- 낮은 신뢰성 -> 상위 계층에서 패킷 분실시 오류 복구
- 따라서, 데이터를 목적지까지 가장 안전하고 빠른 경로로 전달하는 기능(라우팅)이 가장 중요하다
- 대표적인 프로토콜 : IP 프로토콜
- IP 프로토콜 버전 : IPv4(43억개의 주소), IPv6(340조 x 1조 x 1조 개의 주소)
(ex : 라우터, IP)
(4) 전송(Transport)
두 개 컴퓨터에서 전송 시 네트워크 손실이 있거나, 전닱이 안 될 때 체크하게 해서 다시 보내게 해서 정확한 데이터를 받을 수 있게 하는 프로토콜이 속함.
대표적으로 TCP와 UDP가 있는데, TCP는 인터넷 프로토콜(IP) 위에 구축되어 TCP/IP로 합쳐서 부른다.
PORT를 열고, 프로그램들의 전송을 도움
TCP는 Data가 잘 전송되고 있는지 확인하고 만약 중간에 에러가 발생하면 이를 알아내서 다시 에러난 부분을 재전송. 반면 UDP는 Data를 보내는 것 위주로 진행.
TCP는 연결 지향 프로토콜(Connection oriented Protocol), UDP는 비연결 지향 프로토콜(Connectionless Protocol)이다.
전송계층에서 사용하는 PDU(Protocol Data Unit)를 TCP는 세그먼트 UDP는 데이터 그램이라 부름.
4계층에서 사용하는 장비는 게이트웨이가 있는데 데이터가 오고가는 관문 역할을 한다.
(ex : TCP – 신뢰성, 연결지향적, UDP – 비신뢰성, 비연결성, 실시간)
(5) 세션(Session)
데이터가 통신하기 위한 논리적 연결 담당.
통신하는 동안 송신, 수신측이 연결이 유지되도록 도와준다
세션계층은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다.
- 동시 송수신 방식 :duplex
- 두 대의 단말기가 데이터를 송수신하기 위해 동시에 각각 독립된 회선을 사용하는 통신 방식
- 반이중 방식 : half-duplex
- 두 개의 통신장치가 각각의 방향으로 양방향 통신을 할수는 있지만 한번에 한쪽방향으로만 통신이 가능한 통신방식
- 전이중 방식 : Full Duplex
- 두개의 통신장치가 동시에 통신이 가능한 통신방식
- 동시 송수신 방식 :duplex
TCP/IP 세션의 생성/삭제를 담당
통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다룬다.
통신을 하기 위한 세션을 확립/유지/중단 (운영체제가 해줌)
(ex : Socket, API)
(6) 표현(Presentation)
일종의 변역기나 변환기 역할을 수행하는 계층
사용자 시스템의 응용 계층에서 데이터의 형식상 차이를 다루는 부담을 줄여줌
MIME 인코딩이나 암호화, 압축, 코드 변환과 같은 동작이 이루어짐
(ex : MIME, TLS, AFP, SSH 등)
(7) 응용(Applictaion)
최종 목적지. 응용 프로세스와 직접 관계해서 일반적인 응용 서비스 수행
사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스 제공
(ex : HTTP, FTP, DNS)
2. TCP 3 & 4 way handshake
1) 3 way handshake
(1) 클라이언트가 서버에게 SYN 패킷을 보냄(seq=x)
(2) 서버가 SYN(x)를 받고, 클라이언트로 받았다는 신호인 ACK와 SYN패킷을 보냄 (seq=y, ACK=x+1)
(3) 클라이언트는 서버의 응답은 ACK(x+1)와 SYN(y) 패킷을 받고, ACK(y+1)를 서버로 보냄
2) 4 way handshake
- (1) 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보냄
- (2) 서버는 FIN을 받고 확인의 증거인 ACK를 클라이언트를 보냄 (데이터전송을 위해 TIMEOUT)
- (3) 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN을 보냄
- (4) 클라이언트는 FIN을 받고, 확인의 증거인 ACK를 서버에게 보냄 (보내는 동안은 WAIT)
- (5) 서버는 ACK를 받은 후 소켓을 닫고, TIME_WAIT가 지나면 클라이언트도 닫음
- (6) 4번의 통신이 완료되면 연결이 해제됨
3. 대칭키 & 공개키
(1) 대칭키(Symmetric Key)
- 암호화와 복호화에 같은 암호키를 사용하는 알고리즘
- 동일한 키를 주고받기 때문에, 매우 빠름
- 단, 대칭키 전달과정에서 해킹 위험에 노출
(2) 공개키(Public Key)
- 암호화와 복호화에 사용하는 암호키를 분리한 알고리즘
- 자신이 가진 고유한 암호키(개인키)로만 복호화 가능한 암호키(공개키)를 공개
(3) 공개키 암호화 방식 진행과정
- A가 공개된 “B의 공개키”를 이용해 평문을 암호화한 후, “A의 공개키”와 함께 B에게 전송
- B가 본인의 개인키를 사용해 복호화 하여 평문을 확인
- B가 “A의 공개키”를 사용해 응답을 암호화한 후, “B의 공개키”와 함께 A에게 전송
- A가 본인의 개인키를 사용해 복호화 하여 응답을 확인
4. HTTP & HTTPS
(1) HTTP(Hyper Text Transfer Protocol)
- 인터넷 상에서 클라이언트와 서버가 자원을 주고받을 때의 통신 규약
- 텍스트 교환이므로, 전송과정에서 내용을 가로채서 노출 당할 위험이 있음
(2) HTTPS(Hyper Text Transfer Protocol Secure)
- 인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고받을 때의 통신 규약
- HTTP는 텍스트를 암호화한다. (공개키 암호화 방식으로)
(3) HTTPS 통신 흐름
1) 서버A를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만듦
2) 신뢰할 수 있는 CA(Certificate Authority)기업을 선택해, 그 기업에게 공개키 관리위임
3) CA기업은 A서버 공개키, 공개키 암호화방법을 담은 인증서를 만들고 CA기업의 개인키로 암호화해서 A서버에게 제공
4) A서버는 암호화된 인증서를 갖게 됨
5) 클라이언트가 main.html 파일을 달라고 A서버에 요청했다고 가정했을 때,
HTTPS 요청이 아니므로 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받음. (CA 기업의 공개키는 브라우저가 이미 알고 있다.)
6) 브라우저는 해독한 뒤 A서버의 공개키를 얻게 되어 이후 통신이 이루어짐
5. 로드밸런싱(Load Balancing)
(1) 개요
- 웹사이트에 접속하는 인원의 급격한 증가로 서버 1대가 감당할 수 있는 트래픽 수가 너무나 많음. 대응 방안으로는 하드웨어 성능 향상(Scale-up) 또는 여러 대의 서버를 두는 것(Scale-out)임
- 하지만, 하드웨어 성능자체를 올리는 비용이 더 비쌀 뿐더러, 서버가 여러 대라면 무중단 서비스를 제공할 수 있어 Scale-out이 더 효과적임
- 이 때, 여러 서버에 균등하게 트래픽을 분산시켜주는 것을 로드밸런싱 이라 함.
- Client와 Server 사이에 로드밸런서를 하나 두고, 부하가 일어나지 않도록 여러 서버에 분산 시켜 주도록 한다
(2) 로드 밸런서가 서버를 선택하는 방식
- 라운드 로빈(Round Robin) : CPU 스케쥴링의 라운드 로빈 방식 활용
- 최소 연결(Least Connections) : 연결 개수가 가장 적은 서버 선택
- (트래픽으로 인해 세션이 길어지는 경우 권장)
- 소스 (Source) : 사용자 IP를 해싱 하여 분배
- (특정 사용자가 항상 같은 서버로 연결되는 것 보장)
(3) 로드 밸런서 장애 대비
- 로드 밸런서에 문제가 생길 수 있으므로 로드 밸런서를 이중화하여 대비 (Active와 Passive 상태)
6. TCP/IP(Transmission Control Protocol)
흐름제어 & 혼잡제어
- TCP 통신이란? : 네트워크 통신에서 신뢰적인 연결방식.
- TCP는 기본적으로 unrealiable network에서, reliable network를 보장할 수 있도록 한다.
reliable network를 보장한다는 것은 4가지 문제점 존재
1) 손실 : packet이 손실될 수 있는 문제
2) 순서 바뀜 : packet의 순서가 바뀌는 문제
3) Congestion : 네트워크가 혼잡한 문제
4) Overload : reciever가 overload 되는 문제
1. 흐름제어/혼잡제어란?
1) 흐름제어 : 송신측의 데이터 전송량을 수신측에 따라 조절
=> 즉, 흐름제어는 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
2) 혼잡제어 : 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
2. 전송의 전체과정
1) Application layer : 송신 application layer가 socket에 data를 씀
2) Transport layer : data를 segment에 감싼다. 그리고 network layer에 넘김
3) 하위계층에서 receiving node로 전송됨. 이때, sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data 저장
4) application에서 준비가 되면 이 buffer에 있는 것을 읽음
5) 따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것임
6) 따라서 receiver는 RWND(Receive Window) : receive buffer의 남은 공간을 홍보
3. 흐름제어(Flow Control)
- 송신측의 데이터 전송량을 수신측에 따라 조절하는 것을 흐름제어라 부름
- 송신측의 속도가 빨라, 수신측이 데이터 처리를 정상적으로 할 수 없다면 문제 발생
- 수신측에서 제한된 용량을 초과한 이후 도착하는 데이터는 손실 가능성이 크며, 손실될 경우 불필요한 응답과 데이터 전송이 빈번이 발생
해결방법
1) Stop and wait
- 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송
2) Sliding Window
- 매번 ACK를 기다리지 않고, 여러 패킷을 연속해서 송신하기
- 각 컴퓨터의 윈도우 사이즈를 확인하고, 윈도우 사이즈만큼 ACK 없이 연속없이 송신
4. 혼잡제어(Congestion Control)
- 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달.
- 만약, 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 된다.
- 이런 경우, 호스트들은 또다시 재전송을 하게 되고 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시킨다.
- 따라서, 패킷 수가 과도하게 증가하는 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이러한 작업을 혼잡제어라 한다.
7. UDP(User Datagram Protocol)
UDP 통신이란?
- 데이터를 데이터그램 단위로 처리하는 프로토콜
- 비연결형, 신뢰성 없는 전송 프로토콜이다.
- 데이터그램 단위로 쪼개면서 전송을 해야하기 때문에 전송 계층이다.
# 데이터그램 방식 : 패킷 교환에서 각 패킷이 독립적으로 처리되어 목적지까지 도달하는 방식
- TCP와 UDP가 나온 이유
1) IP의 역할은 Host to Host 만을 지원. 장치에서 장치로 이동은 IP로 해결되나, 하나의 장비안에서 수많은 프로그램이 통신할 경우에는 IP만으로 한계가 있음
2) 또한, IP에서 오류가 발생한다면 ICMP에서 알려줌. 하지만, ICMP는 알려주기만 할 뿐 대처하지는 못하여 IP보다 위에서 처리를 해주어야 함
3) 1번 해결을 위해 포트번호가 나오고, 2번 해결을 위해 TCP와 UDP가 나옴
#ICMP: 인터넷 제어 메시지 프로토콜. 네트워크 컴퓨터 내의 오류 메세지를 발생시킴.
* TCP와 UDP가 오류를 해결하는 방법
- TCP : 데이터 분실, 중복, 순서의 뒤바뀜 등을 자동으로 보정
- UDP : TCP와는 다르게 에러가 발생할 수 있음.
* UDP는 왜 사용할까?
- UDP의 주 장점은 데이터의 신속성이다.
- 따라서, 주로 실시간 방송이나 온라인게임에서 주로 사용된다.
DNS(Domain Name Service)에서 UDP를 쓰는 이유
1) Request 양이 작음 -> UDP Request에 담길 수 있음
2) 3 way handshaking이 필요 없음
3) UDP는 비신뢰적이나, 신뢰성은 application layer에 추가 가능하다.
4) DNS : 포트 53번
5) 하지만 크기가 512Byte를 넘으면, TCP를 사용해야 한다
8. 쿠키(Cookie)와 세션(Session)
1) 쿠키
- 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어 있는 작은 데이터 파일
- 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있다.
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시 Request Header를 넣어서 자동으로 서버에 전송한다.
- 쿠키의 동작 방식
- 1) 클라이언트가 페이지를 요청 (사용자가 웹사이트에 접근)
- 2) 웹 서버에서 쿠키를 생성
- 3) 생성한 쿠키를 HTTP 헤더에 포함 시켜 클라이언트에게 응답
- 4) 클라이언트가 쿠키를 가지고 있다가 다시 서버에 요청할 때 쿠키를 함께 전송
- 5) 동일한 웹사이트 재방문 시 클라이언트 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송
2) 세션
- 쿠키를 기반으로 동작하지만, 사용자 정보를 클라이언트 측이 아닌 서버측에서 관리
- 웹사이트의 동시 접속자 수가 많은 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.
클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 Session ID를 부여한다.
- 세션 동작 방식
- 1) 클라이언트가 페이지를 요청 (사용자가 웹사이트에 접근)
- 2) 서버는 클라이언트의 Request-Header Cookie를 확인하여, 클라이언트 Session ID 를 확인
- 3) Session ID가 존재하지 않을 경우, Session ID를 생성하여 클라이언트에게 응답
- 4) Session ID를 쿠키를 사용해 서버에 저장
- 5) 클라이언트 재접속 시, 쿠키를 이용하여 Session ID 값을 서버에 전달
3) 쿠키와 세션 차이
- 사용자의 정보가 저장되는 위치
- 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용한다.
- 보안 우수성
- 쿠키는 클라이언트 로컬에 저장되기 때문에 request에서 스니핑의 위험, 변질 등 보안에 취약
- 세션은 쿠키를 이용해 세션 ID 만 저장하므로 서버에서 처리하기 때문에 비교적 보안성이 좋다.
- 라이플 사이클, 만료 시간
- 쿠키는 파일로 저장되기 때문에 브라우저를 종료해도 정보가 남아 있을 수 있으며, 만료 시간에 따라 쿠키가 삭제 할때까지 유지 기간이 정해진다.
- 세션은 만료 시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다. ex) 크롬에서 다른 탭을 사용할 시 세션 공유, 다른 브라우저 사용 시 다른 세션 사용 가능
- 요청 속도
- 세션은 정보가 서버에 저장되어 있기 때문에 서버 처리가 필요하므로 쿠키에 비해 비교적 느린 속도이다.
9. Keep Alive - HTTP 1.1의 keep alive 기능
- HTTP 기본 구조는 1회성 request와 이에 대한 response로 이루어진다. 따라서, 매번 HTTP request 및 response로 인한 종료시 마다, TCP 프로토콜 단계에서 3-way-handshake 및 4-way-handshake 과정이 필요하다.
- keep alive 기능은 이러한 불필요한 연결과 연결종료 과정을 줄이기 위해, 설정한 keep alive timeout을 설정하여 동일한 source에서 이루어지는 HTTP request에 대해서 연결을 유지하는 기능을 말한다.
- 따라서, keep alive timeout 기간 동안에는 TCP 프로토콜 단계에서, 3-way, 4-way handshake를 수행할 필요가 없으므로, 성능 개선이 가능하다.
10. HTTP 요청 흐름(웹브라우저에서의 요청)
1) 2) 사용자가 웹 브라우저를 통해 찾고 싶은 웹페이지의 URL 주소 입력
3) 사용자가 입력한 URL주소 중에서 도메인 부분을 DNS서버에서 검색
4) DNS 서버에서 해당 도메인에 해당되는 IP주소를 찾아 사용자가 입력한 URL 정보와 함게 전달.
5) 6) 웹 페이지 URL 정보와 전달 받은 IP주소는 HTTP프로토콜을 사용해 HTTP 요청 메시지를 생성. 이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP주소의 컴퓨터로 전송
7) 이렇게 도착한 HTTP 요청 메시지는 HTTP프로토콜을 사용하여 인터넷을 거쳐 해당 IP주소의 컴퓨터로 전송
8) 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색
9) 10) 검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지생성. 이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용해 인터넷을 거쳐 원래 컴퓨터로 전송
11) 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환
12) 변환된 웹 페이지 데이터는 웹 브라우저에 의해 출력되어 사용자가 볼 수 있음.