인터넷
l 저장 후 전달 전송 (Store-and-Forward Transmission)
l 서킷 스위칭, 회선 교한 (Circuit Switching)
l 패킷 교환 네트워크에서의 전체 노드 지연을 일으키는 각각의 지연
프로토콜 계층 Protocl Layers
l ARQ (Automatic Repaet Request) : 자동 재전송 요구, 검출후 재전송 방식
l UDP (User Datagram Protocol)
l NAT (Network Address Translation)
l ICMP (Internet Control Message Protocol)
HTTP
HTTPS (HyperText Transfer Protocol over Secure Socket Layer / TLS / SSL / Secure)
l TLS (Transport Layer Security)
서버 이름 표시 SNI (Server Name Indication)
인터넷
인터넷은 수많은 컴퓨팅 디바이스들이 연결된 컴퓨터 네트워크다.
이를 구성하는 요소들에는 컴퓨터를 포함한 다양한 기기들이 있으며
이 모든 기기들은 호스트 (Host) 또는 종단 시스템 (End System)라고 부른다.
l 종단 시스템 (End System)
개방형 시스템 간 OSI 7계층을 모두 갖춘 시스템,
네트워크에서 서로 통신하는 송신, 수신 시스템을 말한다.
커뮤니케이션 링크, 패킷 스위치의 네트워크에 함께 연결됨
ISP 를 통해 인터넷에 접속한다.
종단 시스템 = 호스트
l 호스트 (Host)
클라이언트 (Client), 서버 (Server)로 나뉜다. 컴퓨터를 포함한 다양한 장치들
l 커뮤니케이션 링크 (Communication link)
구리선, 광케이블 같은 물리적 매체로 만들어짐
서로 다른 링크는 각자 다른 전송률을 갖는다.
l 포트 번호 (Port Number)
IP 주소는 전세계에서 한 컴퓨터에 부여되는 유일한 주소이다.
한 컴퓨터 안에서는 이 IP를 사용하는 어플리케이션 여러 개 일 수 있는데
이 어플리케이션 구분해주는 식별자가 포트 번호이다.
l ISP (Internet Service Providers)
KT, SKT, LG U+ 같은 통신사를 뜻하며
이들은 보유하고 있는 인터넷 회선을 개인이나 기업에게 임대해준다.
IP 할당도 마찬가지
l 패킷 (Packet)
한 종단 시스템이 다른 종단 시스템으로 보낼 데이터 가지고 있을때
송신 종단 시스템에서 그 데이터를 세그먼트로 나누고
각 세그먼트에 헤더를 추가하여 만드는 정보 패키지(묶음)이다.
네트워크를 통해 수신 종단 시스템으로 보내진다.
네트워크 스스로 경로를 설정한다.
목적지 까지 거점들이 있어서 계속 물어보며 가는 방식
어떤 경로 터져도 우회로가 존재
l 패킷 스위치 (Packet Switch)
패킷의 경로를 설정하는 네트워크 장비
1) 라우터 (Router) = 공유기(요즘 공유기는 라우터 기능 포함하고 있음)
경로에 관한 정보를 가지고 있는 테이블 존재
목적지 까지 정보, 테이블 정보를 통해 다음 라우터 까지 경로 설정한다.
방화벽 기능까지 있음
2) 네트워크 코어 (Network Core)
패킷 스위치 네트워크과 종단 시스템들의 연결을 뜻한다.
3) 패킷 스위칭, 패킷 교환 (Packet Switching)
데이터를 패킷 단위로 쪼개서 보내는 것
저장 후 전달 전송 (Store-and-Forward Transmission)
목적지 까지의 노드(패킷 스위치 = 라우터)마다 저장하고 전달하는 방식
하나의 노드로 받아온 패킷을 한번 축적시키고 목적 부호등을 이용하여 상대국을 식별하고 정보를 전송하는것
다시 말해서 outbound 링크로 최초의 패킷 비트를 보내기 전에
전체 패킷을 받아야 함을 의미한다.
공용선을 이용하기 때문에 데이터를 전송하는 통로(링크)를 선점하지 않고
링크에 데이터가 전송 중이면 다른 링크 선택
서킷 스위칭, 회선 교한 (Circuit Switching)
중앙 통제를 받아 경로 설정된다.
집 전화가 이 방식을 사용
소스부터 목적지 까지 회선 전체를 독점하기 때문에 속도가 일정함
목적지 까지 그대로 가면되며, 경로 설정하는 곳이 터지면 사용불가
미리 사용자들에게 공평하게 전송 링크 사용을 할당한다.
반드시 사용을 해야할 경우 사용이 보장되어 있지만
사용하지 않는 사용자들에게도 할당하므로
전송량과 전송속도가 그만큼 나눠지게 됨
패킷 교환 (Packet Switching)
사용자가 필요로 하는 경우에 링크 사용을 할당하기 때문에
사용자 수가 적으면 용량이나 속도에서 이점이 있지만
너무 많으면 사용을 못할 수 있다는 단점이 있다.
소켓 인터페이스
서비스 설명
현재 사람들이 주로 사용하는 프로그램은 대부분 분산 어플리케이션
서로 다른 종단 시스템 위에서 동작하는 분산 어플리케이션은
어떻게 서로에게 데이터를 전달할까?
인터넷에 연결된 종단 시스템은 소켓 인터페이스를 제공한다.
l 소켓 인터페이스 (Socket Interface)
프로그램이 어떻게 다른 종단 시스템에게 전달될 수 있는지 명시하는 것
두 사람이 우편을 주고 받을 때 우체국의 역할을 한다.
통신 규약 (Network Protocol)
네트워크는 사람이 대화하는 것과 유사하게 통신 연결을 요청하면 응답을 보낸다.
언어가 같아야 말을 알아 듣는 것 처럼 소통을 위해서는 다음 세가지 요소의 집합을
통신 규약 (Communication/Network Protocol) 이라고 한다.
둘 이상의 통신 개체 사이 교환하는 메시지 포맷, 순서, 송수신, 다른 이벤트에 따른 행동을 정의한다.
1) 문법 (Syntex)
데이터 형식, 인코딩/디코딩 정보
2) 시멘틱 (Sementic) = 의미
발신과 수신, 이벤트에 대한 정해진 행동을 정의, 에러 처리
3) 타이밍 (Timing)
메시지 속도, 순서(큰 파일을 조각내면 어느 순서로 합쳐야 하는지 알아야 함)
패킷 교환 네트워크에서의 전체 노드 지연을 일으키는 각각의 지연
1. 처리 지연 (Processing Delay)
패킷의 헤더를 조사하여 어디로 보내야할지 결정하는데 걸리는 시간
2. 큐잉 지연 (Queuing Delay)
패킷이 큐에서 링크로 전달되기를 기다릴 때 발생하는 지연
시간이 길어질 수록 전체 지연이 길어지므로 성능이 저하된다.
3. 전송 지연 (Transmission Delay)
패킷이 모든 비트를 링크로 밀어내는데 걸리는 시간
패킷은 FCFS 방식으로 전송됨, 패킷의 모든 비트 도착해야 패킷이 전송가능
전송 지연 = 패킷 길이 / 링크 전송률
4. 전파 지연 (Propagation Delay)
비트들이 링크에 전달되면 라우터로 전파되어야 하는데
그 라우터에 전파되는데 걸리는 시간
비트는 링크의 전파 속도에 따라 전파되며
전파 속도는 링크의 물리적 매체에 따라 다르다.
전파 지연 = 두 라우터 사이 거리 / 전파 속도
l 출력 버퍼/큐 (Output buffer or Queue)
패킷 스위치에는 여러 링크가 연결되어 있고 각각의 링크에 대해 출력 버퍼/큐를 가진다.
출력 버퍼/큐는 링크에 보낼 패킷을 담고 있으며, 패킷 교환에 중요한 역할을 함
l 패킷 손실 (Packet Loss)
패킷이 도착했을 때 이미 버퍼가 가득차 있어서
도착한 패킷이나 큐 안의 패킷이 손실되는 것
프로토콜 계층 Protocl Layers
※ 연결 지향 (Connection Oriented)
통신 연결이 유지되는 것을 지향한다.
유지 비용이 들어서 비쌈
연결이 유지되므로 서로 누군지 알고 있음, 다시 물어보지 않아도 됨
TCP 프로토콜
※ 비연결 (Connectionless) 프로토콜
연결을 유지하지 않는 프로토콜
유지 비용 없어서 싸다.
매번 새롭게 연결이 성립되기 때문에 필요하면 자신이 누구인지 알려줘야 함
HTTP, UDP, IP 프로토콜
※ 계층 구조 Layered Architecture)
기능별로 서로 독립적인 계층(Layer)을 나누는 것
레이어 사이를 연결해주는 것을 인터페이스 라고 한다.
l 통신을 위해 레이어 모델이 지켜야 하는 규칙
- 동일한 레이어 개수
- 동일한 프로토콜
- 동일한 인터페이스
※ 네트워크 레이어 모델
l OSI (Open Systems Interconnection)
국제 표준화 기구 (ISO)에서 만든 공식적 표준 모델
계층이 7개나 되어 잘 쓰이지 않음
l TCP/IP 프로토콜 슈트
미국 방위고등연구계획국 (DARPA)에서 만듬
사실상 표준으로 쓰이는 프로토콜
계층은 4개
응용 계층 (Application Layer)
여러 하위 통신 프로토콜 객체에 대하여 사용 관점의 사용자 인터페이스 제공
하부 계층들을 이용해 사용자에게 편리한 응용 환경을 제공하는 것에 초점을 둠
받은 데이터를 어떻게 활용할지 담당한다.
대상이 되는 프로세서를 식별하기 위해 IP 주소와 포트 번호를 사용한다.
PDU (Protocol Data Unit)는 메시지 또는 데이터라고 한다.
응용 계층의 구현은 사용자 프로그램 환경에서 이루어진다.
응용 계층의 프로그래밍을 위해서는 소켓 프로그래밍을 알아보면 된다.
l 소켓
어플리케이션 계층과 트랜스포트계층의 인터페이스
l IP주소
메시지가 전달되어야할 호스트의 주소를 의미
l 포트 번호 (Port Number)
호스트에서 실행중인 프로세스가 무엇인지 알려주는 것을 포트 번호가 한다.
IP주소를 통해서 메시지를 전달해야하는 호스트 주소를 알았더라면
수신 호스트에서 수행되고 있는 프로세스도 식별해야 하는데
포트번호 그 목적으로 사용된다.0~65535까지의 16bit 정수로 표현됨.
l 프로토콜
1) SMTP (Simple MailTransfer Protocol)
메일 서버간의 전송규약
포트 25
2) POP (Post Office Protocol)
유저가 메일서버에서 메일을 받기위해 사용된다.
포트 POP2(109), POP3(110)
3) FTP (File Transfer Protocol)
파일 전송을 위한 프로토콜
제어연결을 사용하므로 제어정보를 아웃밴드로 보낸다. - 상태유지 어플리케이션
TCP상에서 동작
포트 20(데이터), 21(제어)
Ø 제어 연결
두 호스트 간의 제어 정보(사용자 계정, 비밀번호, 원격 디렉토리를 변경하라는 명령어)등을 보내는데 사용
Ø 데이터 연결
실제 파일을 전송하는데 사용 먼저 제어연결을 하고나서 각 파일마다 데이터 연결을 하는 방식이다.
4) Telnet
원격 서버에 로그인하도록 TCP 연결을 설정하여 직접 조작할 수 있게 해줌
원격 컴퓨터에서 수행한 결과를 단말기에 보여줌
포트 23
5) WWW (World Wide Web)
6) HTTP (HyperText Transfer Protocol)
브라우저는 HTTP를 통해 웹 페이지를 설명하는 HTML 문서를 받아오고
함께 쓰인 CSS를 기반으로 페이지를 렌더링 하고
함께 쓰인 JS를 해석하여 실행함으로써 풍부한 웹 경험을 제공
https://d2.naver.com/helloworld/59361 (브라우저 작동 원리)
HTTP 헤더에는 Content-Type 필드가 있어 포맷 형태를 알려줌
하이퍼텍스트 객체들을 전송하기 위한 프로토콜이고
전송된 파일 자체를 실어다주는 그 TCP연결로 요청/응답을 인밴드로 보낸다. 비상태유지 어플리케이션
7) DNS (Domain Name Service/Service Protocol)
도메인 이름 주소를 통해 IP주소를 확인할 수 있는 프로토콜
포트 53
8) HTTP와 FTP 비교 설명
Ø 차이점
FTP는 파일 전송을 위한 프로토콜
제어연결을 사용하므로 제어정보를 아웃밴드로 보낸다.
상태유지 어플리케이션
HTTP는 하이퍼텍스트 객체들을 전송하기 위한 프로토콜이고
전송된 파일 자체를 실어다주는 그 TCP연결로 요청/응답을 인밴드로 보낸다. 비상태유지 어플리케이션
Ø 공통점
TCP 상에서 동작
9) HTTP와 SMTP를 비교 설명
Ø 공통점
둘다 한 호스트에서 다른 호스트로 파일을 전송하는데 이용,
지속연결을 사용함
Ø 차이점
HTTP는 pull프로토콜 (수신자가 TCP연결 초기화), 메시지 포맷에 제한이 없음, 객체들을 각각 따로 초기화
SMTP는 push프로토콜 (송신자가 TCP연결 초기화), 7비트 아스키포맷, 메시지의 모든 객체를 한 메시지로 만듬
표현 계층 (Presentation Layer)
소켓을 통해 전달받은 데이터를 인식하기 위한 처리를 해주는 계층
번역기와 같은 일을 한다고 보면 된다.
l 압축과 암호화
TLS (Transport Layer Security)은 대중적인 보안을 위한 암호 규약
RPC (Remote Procedure Call)를 통한 데이터 직렬화
XDR (eXternal Data Representation) 프로토콜이 직렬화 프로토콜의 대표
세션 계층 (Session Layer)
프로세스가 통신을 관리하기 위한 방법에 대한 계층이다.
종단 호스트 프로세스 간에 세션을 생성, 유지, 종료하는데 필요한 여러 기능을 제공
l 다중화
여러 세션들이 효율을 높이기 위해 1개의 같은 전송 계층 접속할 수 있음
l 대화 관리
세션 계층은 토큰을 사용함으로써 대화를 관리한다.
누가 언제 통신하였는지 결정하며 토큰을 교환함으로써 구현
프로세스는 토큰을 가졌을 때 전송할 수 있음 (서비스 실행할 권리)
l 에러 복구
전송 시 동기점을 삽입함으로써 메시지를 대화 단위로 그룹화
에러 발생하면 중단된 대화 단위의 처음부터 재전송
l 세션 키 (Session Key)
하나의 논리적 연결 세션 동안 만 유효한 암호 키
전송 계층 (Transport Layer)
어플리케이션 사이에서 어플리케이션 레이어 메시지를 전송하는 역할
PDU (Protocol Data Unit)는 세그먼트(Segment)
세그먼트에 포함되는 전송 계층 헤더에는 포트 번호 필드가 있다.
TCP (Transmission Control Protocol), UDP (User Datagram Protocol) 사용한다.
l TCP (Transmission Control Protocol),
다음의 서비스를 제공한다.
호스트에서만 작동, 중간 라우터에서 작동하지 않음 : 오래 걸리기 때문이다
1) 연결 지향 (Connection Oriented)
2) 신뢰성 있는 데이터 전송 (RDT, Reliable Data Transfer)
3) 연결 제어 (Connection Control)
4) 흐름 제어 (Flow Control)
5) 혼잡 제어 (Congestion Control)
l 다중화 & 역다중화 (Multiplexing & Demultiplexing)
1) 다중화
보통 컴퓨터에 연결된 통신 링크는 하나이기 때문에
하나의 링크를 통해 여러 소켓의 데이터를 주고 받아야 한다.
그래서 전송 데이터를 TCP/UDP 세그먼트로 만들 때
헤더에 출발/도착 포트를추가한다.
소켓으로 부터 데이터를 모아 이에 해당하는 세그먼트를 생성하기 위해서 각각 데이터 헤더 정보로 캡슐화 하고 이 세그먼트를 Network 계층으로 전송하는것
2) 역다중화
도착한 세그먼트의 헤더(포트)를 확인하여 올바른 소켓으로 전송하는 것
l 신뢰성 있는 통신
RDT1.0
신뢰성 있는 채널을 통해 데이터가 전송된다면
에러가 발생하지 않는다는 가정 하의 전송이므로 그대로 줘도 신뢰성 있는 통신임
RDT2.0 (Stop-and-wait 프로토콜)
비트 에러가 존재할 수 있는 상황까지 수용
재전송 기반 에러제어 ARQ (Automatic Repaet Request)를 사용한다.
신뢰성 없는 채널을 통한 통신이 이루어지기 때문에
체크섬 (Checksum)으로 비트 에러가 있는지 감지
에러나면 수신자로부터 피드백을 받을 수 있어야 하므로 ACK, NAK를 보낸다.
이런 식으로 송신 후 기다리기 때문에 Stop-and-wait 프로토콜이다.
RDT2.1
ACK와 NAK 응답도 에러가 발생할 수 있고, 응답이 오지 않으면 무한정 대기함
중복 수신하 가능성도 있음
그래서 2.1에서는 순서 번호 (Sequence number)를 추가하여 중복 수신을 방지한다.
전송이 잘 되었는지만 알면 되기 때문에 번호는 0 혹은 1만 있으면 된다.
RDT2.2
잘못된 수식에 대한 NAK응답이 아닌 ACK를 이용한 방법
ACK에 순서 번호를 추가함으로써 잘못된 데이터를 받은 것을 재송신 할 수 있다.
RDT3.0
패킷이 사라질 수도 있는 채널을 통해 통신한다고 가정
송신자가 ACK를 받는 것에 대한 타임 아웃 타이머를 둬서 해결한다.
하지만 이 방법은 한 번에 한 패킷씩 밖에 보내지 못한다.
따라서 여러 패킷을 보낼 방법을 고민해야 한다.
ACK를 받기 전에 다수의 패킷을 전송하는 방법을 통틀어
파이프라인 프로토콜이라고 하며 다음의 종류가 있다.
ARQ (Automatic Repaet Request) : 자동 재전송 요구, 검출후 재전송 방식
문제 생겼을 때 자동으로 재전송 하라는 거임
1) 특징
Ø 수신측이 송신측에 재전송 요구
데이터 내 첨부된 오류검출(체크섬 등) 정보로 에러 발생 유무 확인
에러 발생한 프레임을 긍정확인(ACK) 및 타임아웃으로 신뢰성 확보
Ø 오류 정정은 할 수 없지만 신뢰성 확보 충분
Ø 실시간 처리에는 곤란함, 낮은 오류 발생률일 때 효과적
2) 필요 기능
Ø 오류 검출
데이터 기반 메커니즘 : 체크섬, 패리티 검사, CRC 등
데이터 내에 부가된 중복요소(리던던시)에 의해 오류검출
시간 기간 메커니즘 : 타이머
송신측은 일정시간(타임아웃) 내 수신측으로부터 ACK도착 안하면
에러 발생 가정
Ø 수신 여부 피드백
긍정 확인 ACK
부정 확인 NACK, 일정시간 ACK 미수신 시(타임아웃)
Ø 재선송의 신뢰화 및 효율화
재전송 신뢰성 확보
시간 기반 재전송 메커니즘 : 타이머, RTO
ACK 기반 재전송 메커니즘 : ACK 메시지의 도착 유무
재전송 효율성 확보
느린 시작 (Slow Start)
혼잡 회피를 위해 초기에 조심스럽게 데이터 송출량을 점증시키며 조사
발신자가 적절한 윈도우 크기를 신속히 찾는데 도움을 줌
단점은 연결 초기 다소 지연
3) 종류
Ø 정지 대기 방식 (Stop and Wait, Idle ARQ)
한 번에 하나씩 ACK을 받고, 후속 데이터 전송
가장 단순하나, 다소 비효율적
반이중 방식에서도 가능
(양 방향 통신 가능, 일정 시각에서는 한 방향으로만 전송 가능한 것)
Ø Go Back n ARQ (GBN) 또는 Continuous ARQ (연속적 ARQ)
슬라이딩 윈도우 (Sliding Window) 방식이라고도 한다.
한번에 여러 개를 보낸후 하나의 ACK받고, 후속 데이터 전송
NAK를 수신할 때까지 계속 데이터 전송
전이중 방식에서 가능
(양 방향으로 동시에 전송이 가능)
여기서 Cumulative ACK를 사용한다.
Cumulative ACK가 n번호를 받았다는 뜻은 n-1까지는 잘 받았으니
이제 n번호를 보내달라는 의미이다
Ø Selective Repeat ARQ (선택적 ARQ, 선택적 재전송)
오류가 발생된 프레임 이후 또는 오류 발생된 프레임 만 재전송
전이중 방식에서 동작함
(양 방향으로 동시에 전송이 가능)
Go Back N ARQ와 동일하지만 손상, 손실이 일어나는 해당 번호만 재전송을 요청한다.
큐를 재정렬 해야되기 때문에 구현하기 어렵다는 단점이 있다.
Ø Adaptive ARQ (적응적 ARQ)
채널 상태에 따라 조절하여 최적을 유지?하는 방법
적절한 타임 아웃 시간 예측
왕복 시간 RTT (Round Trip Time)
인터넷 상에서 상대측 호스트까지 패킷이 왕복하는데 걸리는 시간
영향 주는 요소는 망의 혼잡, 거리, 전송속도 등이 있다.
IP 패킷의 RTT
IP 패킷 왕복시간은 ping 명령어를 통해 RTT및 TTL(IP패킷수명) 알아볼 수 있다.
TCP 세그먼트의 RTT 측정 및 RTO 예측/추정
1) RTT 측정
1 이상의 TCP 세그먼트들이 보내면, 1번 만 확인응답이 이루어지며
그 왕복시간 측정
RTT 측정용 세그먼트 송신부터 확인응답 받기까지 왕복시간 측정
2) RTO (Retransmission Timeout, 재전송 타임아웃 시간) 설정, 계산
전송된 한 세그먼트에 대한 확인응답을 기다려야 하는 시간
TCP 재전송 타이머 값
송신 TCP는 매 세그먼트 전송마다 RTO 가동함, RTT보다 약간 크면 이상적
RTO 계산을 위해 필요한 변수 유지
MRTT (measured RTT, 측정된 RTT) : 측정변수
SRTT (smoothed RTT, 매끄러운 RTT) : 상태변수
RTTVAR (RTT variation, RTT 편차) : 상태변수
RTO : 결과변수 = SRTT, RTTVAR로부터 계산됨
RTO 계산 방법
초기값 = 시스템 마다 다르지만 통상, 3-6초 (표준 권고치 1초)
계산 과정 생략… RTO = SRTT + 4 RTTVAR
결론
RTO는 최근의 SRTT 값에 균형을 위해 작은 RTTVAR의 4배 취한 값을 더함
http://www.ktword.co.kr/abbr_view.php?nav=&m_temp1=1687&id=1102
연결 제어 (Connection Control)
3-way handshaking
TCP 프로토콜에서 신뢰성 있는 통신을 하기 위한 준비 과정으로
서로 연결을 하고 임의의 시작 순서 번호를 알려주는 것
실제로는 수신 기본 윈도우 크기 등 여러 추가 옵션을 교환한다.
1) Client는 연결 요청 메시지를 전송한다.
Option : Syn비트 1
SN 필드 : 랜덤한 값 X (Initial SN 이라고도 함)
PORT상태 : B : LISTEN, A : CLOSED
2) Server는 요청을 수락하고, A에게도 포트를 열어달라는 메시지 전송
Option : Syn, Ack비트1
ACK필드 : X+1값 (A에게서 받은 SN +1)
SN필드 : 랜덤한 값 Y값
PORT상태 : B : SYN_RCV, A : CLOSED
3) Client는 Server에 수락 확인을 보내서 연결을 맺습니다.
Option : Ack비트 1
ACK필드 : Y+1
SN필드 : X+1를 보낸다.
PORT상태 : B : ESTABLISHED, A : ESTABLISHED
추가 설명
SYN (Synchronize sequence number) 필드
ACK (Acknowledgement) 필드
이것과 Option 필드의 안의 Ack, Syn비트는 다른 것이다. 착각하지 말기를
질문
1) Flag Bit란?
TCP Header에는 Code Bit (Flag Bit)라는 부분이 존재한다.
6Bit로 이루어져 있으며 각각의 비트가 의미를 가진다.
Urg-Ack-Psh-Rst-Syn-Fin 순서로 되어 있으며
해당 위치의 비트가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다. SYN 패킷 = 000010, ACK = 010000, FIN = 000001
U : 긴급한 데이터
A : ACK 이용할 때 사용
P : 버퍼링 없이 데이터 바로 보낼 때 사용
R,S,F, : 연결 설정,해제에 사용
2) 랜덤 Sequence Number란?
연결을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다.
따라서 과거에 사용된 포트 번호를 또 사용하게 될 가능성이 존재한다.
만약 난수가 아니라 순차적인 값을 준다면 이전의 연결로부터 오는 패킷으로 인식해버릴 수도 있기 때문에 이러한 문제 발생 가능성을 줄이기 위해 사용
3) PORT 상태
Ø CLOSED : 닫힌 상태
Ø LISTEN : 포트가 열린 상태로 요청 대기
Ø SYN_SENT : SYN 요청한 상태
Ø SYN_RECEIVED : SYN 요청 받고 상대방 응답을 기다리는중
Ø ESTABLISHED : 연결이 확인,확립된 상태
4) 왜 타입이 2개인가
연결이 성립하려면 요청과 응답에 대한 패킷을 주고 받아야 하기 때문
A: 내 말이 잘 들리니? B: 잘들리네,
B: 내 말이 잘 들리니? A: 잘들리네
5) 왜 3방향인가 2방향은 안되는 이유는?
TCP Connection은 양방향 Connection이다.
클라이언트의 요청에 서버가 응답하고
서버의 응답에도 클라이언트가 요청을 해주어야 연결이 성립한다.
6) SYN Flooding
3way handshaking의 취약점을 이용해 서버를 공격하는 방법
Server는 2단계(SYN_RECEIVED 상태)에서
연결을 메모리 공간인 백로그 큐(Backing Queue)에 저장하고
Client응답을 기다리게 되고 일정 시간 동안 응답오지 않으면 타임아웃 시킨다.
이것은 악의적인 공격자가 실존하지 않는 IP로 응답이 없는 연결을 타임아웃 시키기 전에 또 새로운 요청을 무수히 많이 보내어 백로그 큐를 포화상태로 만들어 다른 사용자로부터 연결을 못 받게 하는 공격 방법이다.
대응책으로는 연결 타이머 시간을 짧게 하거나 백로그 사이즈 늘리기,
정해진 시간동안 들어오는 연결 요구의 수를 제한, 쿠키를 이용하여
전체 연결이 설정되기 전까지 자원 할당 연기 등이 있다.
4-way handshaking
연결 종료를 위한 과정이다.
FIN 패킷을 보낸 시점부터 더 이상 데이터 전송이 불가능하다는 것이 핵심
1) A는 연결 해제 요청 메시지를 B에 전송
Option : ACK, FIN 비트 1
ACK 필드 : Y
SN 필드 : X
2) B는 확인 메시지를 보내고 자신의 통신이 끝날 때까지 대기 (TIME_OUT)
남은 데이터 싹다 보냄
Option : ACK 비트 1
ACK 필드 : X+1
SN 필드 : Y+1
3) B는 통신이 끝났으면 연결 종료 요청 메시지를 A에게 보낸다..
Option : ACK, FIN 비트 1
4) A는 연결 해제 요청에 대한 확인 응답 메시지 전송
전송 후 일정 기간 (TIME_WAIT)가 경과한 후에 TCP 연결 해지
이 이유는 아직 서버로부터 받지 못한 데이터 있을 것을 대비해서 잉여 패킷을 기다리기 위함이다.
질문
1) 왜 닫을 때는 4-way 쓰는가
A가 데이터 전송 마쳤다고 하더라도 B가 보낼 데이터 남아있을 경우
A의 FIN에 대한 ACK만 보내고 데이터를 모두 전송한 후에 자신의 FIN을 보내야 하기 때문이다.
(한마디로 남은 데이터를 보내기 위해서다)
2) 만약 Server에서 FIN 전송하기 전에 전송한 패킷이 지연이나 유실로 인한 재전송이 일어나
FIN 패킷보다 늦게 도착하면?
마지막 4단계에 설명을 했듯이 TIME_WAIT 과정에서 처리 (Default : 240s)
흐름제어 (Flow Control)
송신 측이 수신 측의 처리속도 보다 더 빨리 데이터를 보내지 못하도록 제어
1) 송신 제어 방식 = Stop and Wait
한 프레임씩 전송하기 때문에 효율 떨어짐
2) 전송률 기반 흐름제어
3) 윈도우 기반 흐름제어 = Sliding Window
수신 측은 여유 버퍼 공간 크기를 rwnd라는값으로 송신측에게 알려준다.
송신 측은 마지막으로 보낸 데이터 순서 번호(LastByteSent0에서
마지막으로 성공적으로 송신한 데이터 순서 번호(LastByteAcked)를 뺀 것이 rwnd를 넘지 않도록 데이터를 보낸다.
혼잡제어 (Congestion Control)
네트워크가 혼잡하다고 판단될 때 데이터 송신량을 떨어뜨리는 것
혼잡 상태가 일어났을 땐 보통
1) 라우터의 버퍼가 오버플로우 되어 패킷이 손실 (패킷 로스트)
2) 라우터의 버퍼에 대기함으로 인해 평소보다 큰 딜레이 발생 (큐잉 지연)
두 경우 모두 타임아웃으로 알 수 있게 됨
AIMD(Additive Inrease/Multiplicative Decrease)
Slow Start, Fast Retransmit, Fast Recovery 등의 방식이 있지만
공통적으로 송신 측의 전송 버퍼크기 cwnd를 차례로 키워나가다가
전송 실패 시 전송량을 줄인다.
흐름 제어는 (수신 -> 송신 : 야 적당히 보내)
남은 버퍼 공간 크기 rwnd를 수신 측이 알려줘서 송신 측이 조절하도록 하고
혼잡 제어는 (송신 -> 너무 많군, 조절하자)
전송 버퍼 크기 cwnd를 송신 측이 적절한 값을 찾아나간다는 차이가 있다.
결국 min(rwnd, cwnd) 만큼 전송하면 된다.
한 TCP연결에서 과도한 양의 트래픽이 발생하여 통신하는 호스트들 사이의 스위치,링크가 폭주 되는 것을 방지하는 것으로 TCP연결이 링크 대역폭을 공평하게 공유하여 통과하게 해준다.
TCP연결이 링크의 대역폭을 공평하게 공유하여 통과하도록 한다는 설명도 있음
UDP (User Datagram Protocol)
TCP의 여러 서비스를 제공하지 않으면 UDP라고 볼 수 있다.
오버헤드가 매우 적기 때문에 . tcp(20byte), udp(8byte)
많은 요청을 처리하거나 신뢰성이 떨어져도 되는 서비스들에서 유용하게 사용된다.
연결설정이 없어 연결 설정 지연 시간이 없고 더 많은 클라이언트 사용 가능하다.
수신자가 메시지를 받았는지 알 수 없으며, 보낸 순서대로 받는지도 모른다.
기능이 필요하다면 상위 프로토콜 (응용 계층)에서 처리가 필요하다.
따라서 응용 계층이 데이터 송신에 대해 정교한 제어를 할 수 있다.
대표적인 예 : DNS(Domain Name Service, VoIP(음성 인터넷 프로토콜),
온라인 게임 서버 등
| TCP | UDP | |
| 연결 | ⭕ ( Connection-Oriented ) | ❌( Connectionless ) |
| 데이터 경계 구분 | ❌ ( Byte Stream ) | ⭕ ( Datagram ) |
| 신뢰성, 데이터 재전송 | ⭕ ( ARQ ) | ❌ |
| 전송 순서 | 보장됨 | 바뀔 수 있음 |
| 수신 여부 확인 | ⭕ | ❌ |
| 통신 관계 | 1 대 1 ( Unicast ) |
1 대 1 ( Unicast ) 1 대 다 ( Boradcast ) 다 대 다 ( Multicast ) |
| 헤더 크기 | 20 Byte | 8 Byte |
| 속도 | 느림 | 빠름 |
| 용도 | 파일 데이터 전송 |
실시간 스트리밍 |
네트워크 계층 (Network Layer)
전송 계층에서 보내려는 패킷을 목적지 노드까지 도착시키는 것을 담당한다.
중간 라우터를 통한 라우팅과 포워딩, 필요하다면 연결 설정을 담당한다.
l 라우팅 (Routing)
복잡한 네트워크에서 최적 경로가 결정될 수 있도록 라우팅 테이블을 구성
l 포워딩 (Forwarding)
패킷을 다음 장소로 전달하는것
l 포워딩 테이블
입력 포트의 수신 패킷을 어느 출력 포트로 보낼 것인지를 나타내는 표 테이블
입출력 포트 연결 테이블임
목적지 전부를 테이블로 만들기 어렵기 때문에 정확한 주소가 아닌 서브넷으로 구성되어 있다.
l 라우팅 테이블
포워딩 테이블 및 최적 라우팅 정보를 모두 나타낸 표 테이블
라우터 장비에서 관리하며 테이블을 만들기 위해서 여러 라우팅 알고리즘이 존재
l 프로토콜
1) 라우팅 프로토콜
포워딩 테이블을 만들기 위한 프로토콜
2) 인터넷 프로토콜
주소 체계를 위한 프로토콜
3) ICMP 프로토콜
에러 메시지를 전달받기 위해 주로 쓰이는 프로토콜
l 데이터그램 네트워크 (Datagram Network)
데이터그램
발신단말에서 수신단말에 이르는 경로를 결정하기 위한 정보를 내부에 포함하는 패킷, 전송되기 전 연결을 먼저 설정
데이터그램 네트워크에서는 그때그때 받은 데이터그램의 목적지 주소를 확인하여
포워딩 테이블에 따라 출력 링크로 전송한다.
l 인터넷 프로토콜 (Internet Protocol, IP)
호스트의 주소 지정과 패킷 분할 및 조립 기능을 담당
데이터 링크 계층에서 전달할 수 있는 데이터의 최대 크기를
MTU (Maximum Transmission Unit)이라고 하는데
전송하고자 하는 데이터그램이 MTU보다 크다면 데이터그램을 분할하여
offset을 정해준다. 분할된 데이터그램들은 최종 목적지에서 조립된다.
전송 계층 프로토콜의 패킷에서는 포트 번호까지만 나타났지만
IP에서 부터는 IP 주소가 나타난다.
네트워크망 상에서 호스트 또는 라우트 간의 물리 링크 연결을 인터페이스라고 함
IP 주소는 호스트에 부여되는 것이 아닌 인터페이스에 부여되는 것
라우터는 여러 노드와 연결되어 있으므로 여러 인터페이스를 가지고
호스트는 하나의 유선, 무선 연결이 되어 있으므로 하나 이상의 인터페이스 가짐
실제 네트워크 망에서 모든 호스트가 라우터와 직접 연결되어 있진 않고,
중간에 이더넷 스위치 (Ethernet Switch)라는 것들이 있다.
iP 주소로 표현 가능한 주소가 매우 많아서 관리의 효율성을 위해
서브넷이라는 개념이 도입된다.
이에 따라 IP 주소는 서브넷 부분 (상위 비트), 호스트 부분 (하위 비트)로 나뉜다.
서브넷
IP 주소의 서브넷 부분이 같은 노드들을 모아 서브넷이라고 한다.
혹은 라우터 없이 물리적으로 연결된 네트워크망이다.
구, 동, ~로 이런식으로 주소를 나누듯 네트워크망도 계층을 나누어 관리
서브네트워킹 (Subnetworking)
서브넷의 관리를 맡겨버리는 방법
223.1.1.0/24 라는 표현은
상위 24 비트 223.1.1.0가 서브넷이고, 하위비트 /24는 서브넷 마스크이다.
서브넷 마스크 24를 주소로 표현하면 255.255.255.0이며
서브넷 마스크와 IP 주소를 AND 연산을 하면 서브넷 부분만 얻을 수 있다.
클래스 주소 체계는 IP주소의 서브넷 부분을 정확히 8, 16, 24bit로 나누는 방식
A 클래스는 /8
B 클래스는 /16
C 클래스는 /24를 서브넷 마스크로 가진다.
이런 a.b.c.d/x 같은 형식으로 서브넷 부분이 임의의 길이를 가질 수 있는 방법을
CIDR (Classless Inter Domain Routing) 이라고 한다.
l 호스트 주소와 주소 블록 획득
호스트는 어떻게 IP 주소를 부여받을 수 있는가?
IP는 고정, 유동으로 두 가지 방법이 있다.
1) 고정 IP
특정 IP를 아예 호스트로 지정해버리는 방법
2) 유동 IP
IP 주소를 동적으로 획득하는 방법이다.
네트워크에 연결됐을 때만 주소를 가지므로 IP 주소를 재활용 할 수 있음
유동 IP를 지원하는 가장 대중적인 방법은 DHCP을 사용하는 것이다.
DHCP (Dynamic Host Configuration Protocol)
동적으로 네트워크 구성 파라메터를 설정하는 프로토콜
Ø 과정
클라이언트가 DHCP는 찾는 메세지를 브로드캐스트
DHCP는 메세지를 받으면 사용가능한 네트워크 구성 파라메터들을 메세지에 실어서 브로드캐스트함
클라이언트는 IP를 할당받고 DHCP에게 이 IP를 사용하겠다고
메시지를 보내서 알림 (이 시점에는 DHCP의 주소를 알고 있음)
DHCP는 메세지 받고 확인 메세지를 보냄 (DHCP도 IP 주소를 알고 있음)
Ø 장점
누구나 쉽게 할 수 있다는 것과, 대량의 컴퓨터 관리시에 편리하고
주소를 사용하지 않을 때 다른 곳에 사용 할 수 있다.
Ø 단점
IP가 변하기 때문에 서버로 사용할 수 없다.
여러 호스트로 이루어진 서브넷을 만들어 관리하고 싶다면 주소 블록이 필요
주소 블록은 어떻게 획득할까?
ISP에게 돈 주고 사면 된다. ISP는 더 상위의 IP 주소 관리 단체 ICANN로부터
주소 블록을 발급받아 블록을 쪼개어 고객들에게 판다.
- Hierarchical Addressing
ISP는 인터넷 망에게 자신의 주소 블록을 목적지로 하는 패킷들을 모두 보내라고 광고한다.
넓은 서브넷상으로 라우팅 된 패킷이 ISP 망 내에 도착하면 또다시 더 좁은 서브넷으로
라우팅 되기를 반복할 것. 이러한 방식을 말한다.
NAT (Network Address Translation)
하나의 IP 주소를 갖고 여러 호스트를 관리하는 방법
NAT 장비 내부에는 지역 네트워크가 형성되고, 지역 네트워크 상의 주소를
NAT 장비가 관리한다.
지역 네트워크에서 패킷이 외부로 나갈 때 NAT 장비를 거쳐서 NAT 장비의 주소로 변경된다. IP가 변경되고 포트 번호는 유지되므로
반대로 외부에서 지역 네트워크로 진입하고자 하는 패킷은 이 포트 번호를 보고
사설 IP정보를 찾아오게 됩니다. (PAT, Port Address Translation)
PAT은 Dynamic NAT의 한 종류라고 볼 수 있으며
공인 IP 주소 1개에 여러 사설 IP 주소를 포트번호를 붙여 매핑하는 것이다.
요약
사설 IP를 공인 IP를 바꿔주는 통신망의 변환기 역할을 함
외부로는 공인 IP를 알리고 내부에서는 사설 IP를 사용한다.
공인 IP를 아낄 수 있고, 사설망을 침입자로 부터 보호할 수 있다.
ICMP (Internet Control Message Protocol)
호스트와 라우터 사이의 네트워크 계층 정보를 통신하기 위해 사용되는 프로토콜
ping, traceroute라는 프로그램에서 쓰인다.
traceroute는 어떤 경로를 거쳐 호스트에 도착하는지 확인할 수 있어
네트워크 관련 문제를 디버깅하고자 할 때 유용함
라우팅 방식 구분
1) 정적 라우팅 (Static Routing)
모든 네트워크에 대한 경로를 관리자가 수동으로 설정하여 관리
처리 부하가 적어서 속도가 빠르다. 단일 경로에 적합, 변경 적으면 유리함
관리자가 네트워크 정보 모두 알고 있어야 한다는 부담을 덜기 위해
Default Gateway를 사용한다.
2) 동적 라우팅 (Dynamic Routing)
라우터에 동적으로 경로에 대한 정보를 수집할 수 있는 라우팅 프로토콜 설정
관리자의 개입 없이도 라우터에서 모든 정보 설정할 수 있도록 하는 방법
Ø IGP (Interior Gateway Protocol)
동일 AS (Autonomous System) 안에서 서로 경로 정보를 주고 받음
RIP (Routing Information Protocol),
OSPF (Open Shortest Path Frist),
IGRP (Interior Gateway Routing Protocol)
Ø EGP (Exterior Gateway Protocol)
AS 사이에서 경로 정보 주고 받는 라우팅 프로토콜
3) 플러딩 (Flooding)
브로드캐스트 방법 중 하나로
먼저 링크에 연결된 모든 노드로 패킷을 보내고
받은 쪽을 제외하고 다시 나머지로 패킷을 보낸다.
이를 반복하면 모든 노드로 패킷을 보낼 수 있다.
장점
굉장히 빠른 속도로 보낼 수 있다.
주소를 몰라도 보낼 수 있다.
다 고장나고 하나만 남아도 보낼 수 있다.
단점
트래픽이 많이 발생
l 라우팅 알고리즘
크게 Distance Vector, Link State, Hierarchical Routing 세 가지로 나뉜다.
1) Distance Vector
목적지까지 모든 경로를 저장하지 않고 목적지까지의 거리 (Hop count)와 방향(Vector)만을 저장하는 방식
일정 주기마다 정보를 전달 받으면 자신의 라우팅 테이블을 갱신하고 그 정보를 인접 라우터에게 전달한다.
라우팅 테이블 변화가 생겼을 때 전파하는 데 오래 걸린다.
벨만-포드 알고리즘이 사용된다.
RIP, IGRP이 대표적이다.
2) Link State
경로 선택 기준은 비용(Bandwidth, Reliability, Delay) 즉 링크의 상태에 따라 결정된다.
모든 경로 알고 있으므로 라우팅 테이블 변화에 따른 전파 속도 빠르며
주기적인 업데이트가 아닌 변화가 있을 때만 업데이트한다.
다익스트라 알고리즘 쓴다.
라우터가 모든 목적지까지 경로를 저장해야 하기 때문에 메모리 많이 소모,
OSPF 프로토콜이 대표적임
3) Hierarachical Routing
인터넷을 AS (Autonomous System)라는 더 작은 구역(Region)으로 나눈다.
AS는 관리자에 의해 운영되며 각자의 라우팅 프로토콜을 사용
AS 내에서의 라우팅을 위한 프로토콜을 IGP (Interior Gateway Protocol)
라고 하며 OSPF, RIP 프로토콜이 주로 쓰인다.
반명 AS 외부로의 라우팅을 위해서는 EGP가 사용되며 주로 BGP (Border Gateway Protocol)이 사용됩니다.
데이터 링크 계층 (Datalink Layer)
비신뢰적 물리 회선을 신뢰적 링크로 변환시키는 계층
3계층 프로토콜을 전송/운반/전달하는 역할을 한다.
데이터 단위 (PDU)는 프레임이다.
l 프레임
1) 프레임화 (Framing)
데이터 그램에 헤더와 트레일러를 추가하여 프레임으로 캡슐화하는 작업
헤더 - 출발, 목적지의 MAC 주소
트레일러 – 오류 검출용으로 프레임 체크 문자열 (FCS), 순환 중복 검사 (CRC)
2) MTU
프레임 길이의 상한선, 최대전송단위
l 주소
이 계층에서 사용되는 주소는 MAC (Media Access Control) 주소이다.
IP 주소는 바뀔 수 있지만 MAC 주소는 네트워크 인터페이스에 할당된 고유 식별자로 IP 패킷을 전송하기 위해 물리적 네트워크 주소인 MAC 주소가 필요한데,
이를 모를 때 ARP를 이용한다.
ARP (Address Resolution Protocol)
네트워크 계층 주소와 링크 계층 주소사이의 변환을 담당하는 프로토콜
송신 호스트의 MAC주소는 자신의 LAN 카드를 읽으면 되지만
수신 호스트의 MAC주소는 알 수 없기 때문에 IP주소를 매개로 ARP를 이용하여 MAC주소를 알아내야 한다.
Ø 과정
ARP request라는 특수 패킷을 브로드캐스팅하면
자신의 IP주소와 동일한 호스트가 ARP reply 패킷에 자신의 MAC주소를 담아 전송
l 흐름제어 (Flow Contorl)
수신측과 송신측의 속도 차이를 조절하는 것
l 에러제어 (Error Control)
물리 전송 매체의 특징상 오류와 잡음이 랜덤하게 발생할 확률이 높으므로
전송 오류를 검출하고 수정한다.
검출은 패리티 검사, 체크섬, 순환 중복 검사 (CRC)
수정은 부호어 (Cordword), 헤밍 부호 (Hamming Code) 등이 있습니다.
정확하게 수신되지 않은 패킷들을 재전송 (ARQ)
l 순서화 (Sequencing)
순서 번호 (Sequence number)를 부여하여 순서가 혼동되지 않도록 함
l 장비
1) 스위치
스위치 장비는 내부적으로 MAC 주소 테이블을 가지고 있다.
테이블을 참조하여 목적지 MAC 주소의 포트에 연결된 노드에 패킷을 전송
물리 계층 장비인 허브와 다르게
연결된 장치의 수와 관계없이 대역폭을 그대로 전달한다.
또한 가상 랜 (Virtual LAN)을 지원한다.
목적지로만 패킷을 전송하기 때문에 스니핑 불가 -> 스니핑 하는 기법이 있다.
2) 브릿지
네트워크와 네트워크를 연결하는 장비
패킷의 목적지 주소를 읽어 전송하는 역할을 한다.
물리적으로 떨어진 동일한 LAN을 연결해주는 장비
스위치는 하드웨어 기반이지만 브릿지는 소프트웨어 기반이다.
요즘은 브릿지 역할을 라우터가 대체하고 있음
다중 액세스 프로토콜
각 노드가 채널을 어떻게 공유할 것인가를 결정하는 채널 분할 알고리즘
1) 채널 분할 프로토콜
채널을 작은 조각으로 분할하여 각 노드에게 할당
Ø TDMA (Time Division Multiple Access)
채널에 반복 순환 방식으로 접근
각 스테이션은 자신의 순서마다 고정 길이의 시간슬롯 동안 전송 가능
사용되지 않는 슬롯 낭비
Ø FDMA (Frequency Division Multiple Access)
채널을 서로 다른 주파수 대역으로 분할
각 스테이션은 고정된 주파수 대역을 할당 받는다.
전송할 데이터 없으면 해당 주파수 대역 낭비
Ø CDMA (Code Division Multiple Access)
각자 서로 다른 코드 셋을 가진다.
2) 랜덤 액세스
채널을 분할하지 않고 충돌을 허용, 충돌하면 복구한다.
Ø 슬롯 알로하 (Slotted ALOHA)
(C : Collision, S : Success, E : Empty)
노드는 전송할 프레임이 있을 때, 다음 슬롯이 시작할 때까지 대기했다가 그 슬롯에 전체 프래임을 전송
충돌이 없다면, 노드는 성공적으로 프레임 전송한 것
충돌 발생하면, 충돌 없이 전송될 때까지 확률 p로 해당 프레임을 다음 슬롯들에서 재전송한다.
장점
하나의 활성 노드는 채널 전체 대역폭으로 계속해서 전송 가능
각 노드가 충돌을 감지하고 언제 재전송할지 결정하므로 분산화
단점
충돌은 슬롯을 낭비시킨다.
각 노드들의 확률적인 전송 정책으로 비어있는 슬롯 발생
모든 노드는 동기화 되어야 함
Ø 알로하 (Pure ALOHA)
슬롯이 없고 완전히 분산화
프레임 도착시 프레임 전체를 브로드캐스트 채널로 전송
Ø CSMA (Carrier Sense Muliple Access)
전송하기 전에 감지 !
만약 채널이 비어있는 것으로 감지되면, 전체 프레임 전송 비어있지 않다면, 전송 연기
충돌 검출 !
만일 다른 노드가 방해 프레임 전송하고 있음을 검출하면
자신의 전송 중단하고 다음에 언제 전송할 지를 프로토콜 사용해 결정
CSMA collision !
충돌이 여전히 발생, 충돌시 전체 패킷 전송시간 낭비된다.
Ø CSMA/CD (Carrier Sense Muliple Access / Collision Detection)
전송하기 전에 회선이 사용중인지 감시하고 있다가 비면 데이터 전송
그런데 동시에 여러 노드에서 데이터를 전송할 경우 충돌할 수 있다.
충돌을 검출하면 일정 시간 전송을 중단했다가 다시 신호를 보낸다.
그래서 대역폭 낭비를 줄일 수 있다.
CS : 네트워크가 사용중인지 확인
MA : 네트워크가 비어있으면 누구든 사용 가능
CD : 충돌 여부를 감지 = 다른 프레임의 비트가 발견되면 충돌로 판단
유선 이더넷 LAN에서 사용한다.
버스형 구조의 LAN을 제어하기 위해 쓰임
Ø CSMA/CA (Carrier Sense Muliple Access / Collision Avoidance)
스테이션이 전송하기 전에 채널을 감지하고 사용중이면 전송하지 않는다. 충돌 검출이 아닌 충돌 회피 기술을 사용함.
데이터 전송이 없는 경우라도 충돌을 대비하여 확인을 위한 신호를 전송
확인 신호가 충돌없이 전송된 것을 확인하면 데이터를 보낸다.
네트워크 사용 빈도가 많아져서 충돌 방지의 신호가 흐르는 속도가 매우 느려지며 전송도 많이 지연된다. 그래서 /CD 방식보다 많이 사용 안함
IEEE 802.11 무선LAN 또는 무선 이더넷에서 사용하는 프로토콜이다.
무선 네트워크에서는 충돌 감지가 힘들기 때문에 CSMA/CD를 사용 못함
충돌 검출할 수 있는 하드웨어 만드는데 비용이 많이듬
숨은 터미널 문제, 페이딩 때문에 충돌을 검출하지 못할 수도 있음
숨은 터미널 문제(Hidden Terminal Problem)
A와 C는 서로의 신호를 수신할 수 없으므로
전송 전이나 전송 중에 충돌을 감지할 수 없어 CSMA/CD가 작동하지 않고
충돌이 발생하여 수신 한 데이터가 손상됩니다.
페이딩(Fading)
신호가 무선 매체를 통과함에 따라 신호 세기가 감소함으로 인해
수신 측에서 충돌을 검출하지 못하는 현상.
충돌 회피 방법에는 다음의 방법이 있다.
프레임 간 공간 IFS (Inter Frame Space)
휴지(Idle) 상태의 채널이 발견된 즉시 전송하지 않는 것
휴지 상태인 것처럼 보이지만
멀리 떨어져 있는 지국이 이미 전송을 시작했을지도 모르기 때문이다.
이런 경우 IFS동안 대기하여 회피한다.
다툼 구간 (Contention Window)
다툼 구간은 Time-slot으로 나뉘어져 있는 일정 시간이다.
전송할 준비가 되어있는 지국은 임의의 수를 선택하여 그 만큼 대기한다.
이 구간에서는 지국이 매 타임슬롯 뒤에 채널을 감지한다.
채널이 사용 중으로 감지되면 타이머를 멈추고 휴지 상태가 감지되면 다시 타이머를 작동한다. 오래 기다린 지국이 우선순위 가짐
3) 순번 프로토콜
각 노드는 순서를 갖는다.
전송할 데이터가 더 많은 노드는 더 긴 시간 동안 전송될 수 있다.
Ø 풀링 프로토콜
마스터 노드가 전송 순서대로 슬레이브 노드를 지정
Ø 토큰 전달 프로토콜
토큰이라는 특수 목적 프레임을 정해진 순서대로 노드 사이에서 주고 받는다. 토큰 수신시 전송할 프레임이 있을때만 토큰 붙잡아 두고 프레임 전송
물리 계층 (Physical Layer)
물리적으로 비트를 전송하기 위한 수단을 제공하는 계층
실제 장치들을 연결하기 위한 물리, 전기, 기계적 세부 사항을 정의
전기적 신호를 비트열로 복원하여 데이터 링크 계층에 전달
전달만 할 뿐 에러나 효율성에 대해 관여하지 않는다.
PDU는 비트이다.
l 장비
1) 케이블 (통신 매체)
동축, UTP, STP, 광케이블
2) 허브
여러 장비들을 케이블을 사용하여 연결해 주는 장치
망가진 신호부분을 복구하지 않고 단순히 증폭만 시켜줌
반이중 (Half,-Duplex)로 동작한다. 증폭하면서 충돌할 수도 있기 때문임
단점은 대역폭을 연결한 장치 수 만큼 나눠서 제공한다는 것이다.
매우 비효율적이기 때문에 요즘은 스위치가 허브를 대체하고 있음
3) 리피터
수신된 신호를 받아 증폭시켜줘서 전송거리를 확장시키는 장치
하지만 UTP, 광케이블 등 성능 좋은 케이블 등장으로 사라짐
이더넷, 토큰 링 등이 이 계층에 포함되며
전기 신호 또는 광 통신 등이 있다.
전기 신호는 멀리 이동할수록 약해지므로 다시 증폭시키기 위한 허브, 리피터 사용됨
옛날 전화선을 이용하던 모뎀 (디지털 신호, 아날로그 신호 변환기)이 이 계층에 속함
l 프토로콜
1) Ethernet
데이터 단말장치와 모뎀을 접속하기 위한 인터페이스 규격
TokenRing, FDDI, X.25…
Nagle 알고리즘
한번의 세그먼트로 전송할 수 있는 데이터를 여러 번 나눠서 보내면 전송 효율이 떨어진다.
그래 필요 이상의 작은 세그먼트를 버퍼에 모아서 한 번에 보내는 기법이다.
Stop And Wait 프로토콜의 경우
송신측이 패킷을 보내고 수신측으로부터 ACK를 받아야 다음 패킷을 보낸다.
Nagle에서는 다음 ACK를 받을 때 까지 패킷 정보를 송신 버퍼에 저장한다음
ACK를 받으면 여러 개의 패킷을 모아서 한번에 전송하여 전송 효율을 높인다.
1) 장점
같은 양의 데이터라도 한 번에 많이 보내기 때문에
데이터 전송 횟수가 줄어서 네트워크 효율 증가
2) 단점
ACK를 받을 때까지 패킷을 모으고 있기 때문에 반응 속도 저하
그서 반응, 응답이 중요한 게임, 리얼타임 시스템의 제어, 키 입력에서 사용하면 안된다.
HTTP
웹 상에서 클라이언트와 서버 간에 요청/응답으로 정보를 주고 받을 수 있는 프로토콜
l 특징
주로 HTML 문서를 주고받는 데 쓰인다.
TCP, UDP를 사용
포트번호 80번
비연결 – 요청에 대한 응답을 보내면 바로 연결이 끊긴다.
무상태 – 연결을 끊는 순간 통신이 끝나며 상태 정보를 유지하지 않는다.
l 요청 응답 헤더
1) General Header
요청, 응답 메시지 모두에서 사용 가능한 일반 목적 헤더
- Date : HTTP 메시지 생성 일시 (Date: Sat, 2 Oct 2018 02:00:12 GMT)
- Connection : 연결에 대한 옵션 설정 (Close, Keep-Alive)
- Cache-Control
- Pragma
- Trailer
2) Entity Header
요청 응답 메시지 모두에서 사용 가능한 Entity(콘텐츠, 본문, 리소스) 설명 헤더
- Content-Type : 개체에 포함되는 미디어 타입 정보를 표현한다.
컨텐츠 타입(MIME 미디어 타입), 문자 인코딩 방식 지정
type/subtype으로 구성된다.
Content-Type: text/html; charset-latin-1
설명 : html으로 표현된 텍스트 문서, iso-latin-1 문자 인코딩 방식으로 표현
Text Type 으로는 text/css, text/javascript, text/html, text/plain 등이 있다.
html문서에 type을 명시할 땐 text/javascript, text/css등이 있다.
File을 실어보내기 위한 type으로는 multipart/formed-data등이 있다.
Application type으로는 application/json, application/x-www-form-urlencode등이 있다.
W3 문서에 따르면 application/x-www-form-urlencode를 사용할 때 body를 encoding 하는 것이 필수다.
브라우저에서는 아마 대부분 기본적으로 해당 content-type에 대해 encoding 하도록 구현해 놓았을 것임, 그래서 우리가 주의해야 할 것은
application logic에서 application/x-www-form-urlencode를 사용할 경우
body 인코딩이 해당 framework 혹은 library에서 자동으로 되는지 확인 후 안되면 해야한다.
- Content-Language : 해당 개체와 가장 잘 어울리는 사용자 언어 (자연어)
- Content-Encoding : 해당 개체 데이터의 압축 방식
압축이 되었다면 Content-Encoding과 Content-Lengh로 압축 해제 가능
- Content-Length : 개체의 바이트 길이/크기 (10진수)
- Content-Location : 해당 개체가 실제 어디에 위치하는가 알려줌
- Contnet-Disposition : 응답 Body를 브라우저가 어떻게 표시해야 할지 알려줌
inline : 웹페이지 화면에 표시, attachment : 다운로드
attachment의 경우 filename 옵션으로 파일명까지 지정 가능
- Content-Security-Policy : 외부 파일을 불러올 경우, 차단할 소스와 불러올 소스 명시한다. 이를 통해 XSS 공격에 대한 방어 가능
예를 들면
Content-Security-Policy: default-src https: https를 통해서만 파일 가져옴
- Location : 리소스가 리다이렉트된 때에 이동된 주소, 또는 새로 생성된 리소스 주소
300번대 응답이나 201 Created응답일 때 어느 페이지로 이동할지 알려줌
새로 생성된 경우 201 Created가 반환됨
- Last-Modified : 리소스를 마지막으로 갱신한 일시
3) Request Header
요청 메시지에서만 나타나며 가장 방대함
- Host : 요청하는 호스트명, 포트번호 (필수)
Host 필드에 도메인명, 호스트명을 모두 포함한 전체 URI 지정 필요함
URL (Uniform Resource Locator) 이 URI(Uniform Resource Identifier)의 일반적인 형식
이에 따라 동일 IP를 갖는 단일 서버에 여러 사이트 구축 가능
- User-Agent
- From
- Cookie
- Referer
- If-Modified-Since
- Authorization
- Origin
- Accept
- Accept-Charset
- Accept-Encoding
- Accpet-Language
4) Response Header
l 버전
1) HTTP/1.0
요청을 날릴 때마다 연결을 새로 생성, 성능 좋지 않고 비효율적
2) HTTP/1.1
지속 커넥션 (Persistent Connection)과 HTTP 파이프라이닝 개념 추가.
연속적인 요청 사이에 커넥션을 유지하여 새 커넥션 여는데 필요한 시간 단축
응답 기다리지 않고 연속적인 요청을 보내서 네트워크 지연 줄인다.
요청을 미리 여러 서버에 날릴 수 있게 되었다.
3) HTTP/2
커넥션 관리의 몇가지 모델을 더 추가
end-to-end가 아닌 hop-by-hop인 두 개의 연속된 노드 사이의 커넥션에 적용
클라이언트와 첫 번째 프록시 사이 커넥션 모델은
프록시와 서버 또는 다른 프록시 사이의 커넥션 모델과 다를 수 있다.
탄생 배경
옛날에 비해 웹페이지에 필요한 리소스의 양이 많아졌고, 비해 웹페이지가 동적으로 작동된다.
HTTP1은 앞에서 전송한 요청의 응답을 받아야만 다음 요청이 처리될 수 있다.
HOL (Head Of Line Blocking) 의 영향을 받는다.
: 처음 요청에 문제가 있어서 응답 늦어지면 이후 요청도 늦어지는 문제
이를 해결하기 위한 최적화 방법 중 하나는 도메인 샤딩인데
HTTP2에서 멀티플렉싱 개념이 도입되면서 도메인 샤딩 안쓰게 되었다.
Binary Protocol
기존 HTTP/1은 플레인 텍스트로 구성되어 있었는데
HTTP/2에서는 데이터를 전송할 때, 바이너리로 인코딩하여 전송한다.
HTTP/1.1에서 HTTP요청, 응답은 메시지 단위로 구성되어 있었는데
HTTP/2에서는 Frame, Stream 개념이 추가되었다.
Frame이 모여 Message가 모여 Stream
1) Frame
HTTP/2 통신에서 주고 받을 수 있는 가장 작은 단위이며
메시지는 다수의 Frame으로 구성된다.
2) Stream
클라이언트와 서버사이 맺어진 연결을 통해 양방향으로 데이터를 주고받는
한 개 이상의 메시지를 의미한다.
그래서 HTTP/2에서는 Stream하나가 다수의 요청과 응답을 처리할 수 있는 구조로 바뀌어서 동시에 여러 메시지를 처리할 수 있게 되었고 요청 순서에 상관없이 만들어진 순서대로 클라이언트에 전달할 수 있게 되었다.
그렇기 때문에 HOL 이슈에서 벗어날 수 있음
최적화
성능 향상을 위해 요청수를 줄이기 위한 방법
1) 이미지 요청수 최적화 – Image Splite CSS
큰 전체 이미지를 한 번에 받아와서 CSS로 이미지를 쪼개서 웹페이지에
보여주는 방법으로 실서비스에서도 자주 사용된다.
2) 이미지 요청수 최적화 – Data URI Scheme
이미지를 BASE 64인코딩을 사용해서 이미지를 코드로 보여주는 방식
3) JS/CSS 리소스 요청수 최적화 – 파일 압축
레일즈 Production 환경에서는, JS와 CSS가 각각 한 파일에 자동으로 압축되어
사용된다. 파일이 여러 개 있으면 각각 연결을 맺어서 다운로드 받아야 하기 때문이다.
HTTP/2에서는 이러한 노력하지 않아도 Server Push가 있다.
원래 웹 브라우저가 웹페이지 보여주는 절차는
1) 어플리케이션에서 HTML 태그 데이터 내려준다.
2) 브라우저는 태그를 파싱해서, 또 요청 날려야하는 리소스 파악한다.
3) CSS,JS,Image 등을 요청해서 받아온다.
4) 브라우저에 그린다.
이러한 과정으로 웹 브라우저에서 리소스를 보려면 계속 기다려야 한다.
Sever Push란
브라우저에서 필요한 리소스들을 서버가 알아서 찾아다가 내려주는 것
HTML 태그에서 필요한 리소스가 뭔지 찾기 전에,
HTML 태그를 받은 즉시, 리소스를 페이지에 그릴 수 있게 되었다.
사용방법은 Link라는 Header에 Push할 리소스를 추가해주면 된다.
캐싱되지 않은 리소스 받아올 때,
페이지에서 필요한 리소스가 페이지를 내려주는 서버에 있을 때 유용하다.
만약 캐싱되어서 재사용되는 리소스를 Push하거나
CDN 처럼 다른 서버에서 내려주는 리소스 때문에 Blocking 걸리는 경우 성능 향상 없다.
헤더 압축으로 인한 성능 향상 - HPACK 압축 방식
HTTP/1 시대에는 Header가 점점 뚱뚱해져서, 주고 받아야하는 데이터 중
디폴트로 딸려오는 헤더 데이터가 무척 컸다.
HTTP/2 에서는 Header를 Header Table로 압축해서 관리한다.
또한 이전 리퀘스트에서 중복으로 선언된 헤더는 인덱스 값만 전송하여
전송 데이터양 최소화 한다.
새롭게 추가되거나 변경된 헤더는 허프만 인코딩되어 전송된다.
HTTP2를 사용할 수 있도록 세팅하려면 어떻게 해야하는가?
HTTP2는 TLS 기반에서 작동되기 때문에, TLS/SSH 인증서가 필요하다.
인증서를 받아서 설정하고 HTTPS에서도 웹페이지가 동작하도록 수정
또한 HTTP2를 지원하는 네트워크 인프라 세팅이 필요하다.
엔진엑스는 HTTP2 기본 지원, 아파치도 HTTP2 모듈 지원
l 단기 커넥션
HTTP/1.0의 기본 커넥션
각각의 HTTP 요청은 각각의 커넥션 상에서 실행된다.
영속 커넥션을 지원하지 않는 옛날 시스템을 다루는 것이 아니라면 사용x
새로운 연결을 맺는데 시간을 많이 소비, TCP기반 커넥션의 성능은 오직 커넥션이 예열된 상태일 때만 나아진다
-> ???
HTTP/1.0 : Connection 헤더가 존재하지 않거나, 값이 Close로 설정된 경우
HTTP/1.1 : Connection 헤더가 Close 값으로 설정되어 전송된 경우에만 사용
l 영속 커넥션 (Keep-Alive 커넥션)
얼마간 연결을 열어놓고 여러 요청에 재사용함으로 써,
새로운 TCP Handshaking 비용을 아끼고, TCP 성능 향상 기능을 활용할 수 있다.
커넥션은 영원히 열려있지는 않고, keep-Alive헤더를 통해 시간 조절 가능
HTTPS/1.0 커넥션은 Connection 헤더를 retry-after로 설정하면 영속적으로 동작
단점
유휴 상태일 때도 서버 리소스를 소비, 과부화 상태에서는 DoS attacks를 당할 수 있다. 이런 경우 커넥션이 유휴 상태가 되자마자 닫는
비영속적 커넥션을 사용하는 것이 더 나은 성능 보일 수 있다.
l HTTP 파이프라이닝
영속 커넥션을 통해서, 응답을 기다리지 않고 요청을 연속적으로 보내는 기능
이것은 커넥션 지연을 회피하기 위한 방법이다.
이론상 두 개의 HTTP요청을 하나의 TCP 메시지 안에 채워서 성능을 더 향상시킬 수 있다.
GET, HEAD, PUT, DELETE 메서드 같은 idempotent 메서드만 가능하다.
실제로 많은 프록시와 서버들은 제한을 가지고 있기 때문에
모던 브라우저에서 기본적으로 활성화되어 있지 않습니다.
버그가 있는 프록시들이 여전히 많으며, 이들은 예상, 분석이 힘들고 오류가 있는 동작을 야기한다.
파이프라이닝은 정확히 구현하기 복잡하다.
HOL (Head Of Line Blocking) 문제에 영향을 받는다.
l 도메인 샤딩
요청 사이에 실제 정렬이 없음에도 HTTP/1.x 커넥션이 요청을 직렬화합니다.
대역폭이 큰 경우가 아니면 효율적이지 못함. 그래서 이를 피하기 위해
브라우저들은 각 도메인에 대한 몇 개의 커넥션을 맺고 병렬로 요청을 보냅니다.
서버가 더 빠른 반응을 원한다면 더 많은 커넥션을 열도록 강제할 수 있다.
하나의 도메인에서 모든 리소스 가져오는 데신 여러 개의 도메인으로 분할할 수 있고
이러한 도메인들은 동일 서버로 연결되고, 브라우저는 각각 도메인마다 6개의 커넥션을 맺는다. 이러한 기법을 도메인 샤딩이라고 함
HTTP/2에서 도메인 샤딩은 더 이상 유용하지 않다.
HTTP/2 커넥션은 우선 순위가 없는 병렬 요청들을 매우 잘 다룬다.
도메인 샤딩은 성능 측면에서 좋지 못함.
대부분 HTTP/2 구현체는 우발적으로 일어나는 도메인 샤딩 되돌리기 위해
커넥션 합치기 (Connection Coalescing) 기술 사용한다.
쿠키 / 세션
l 쿠키
서버측에서 클라이언트 측에 상태 정보를 저장하고 추출할 수 있는 매커니즘
클라이언트의 하드에 텍스트 형식으로 했다가 필요할 때 참조, 재사용
한 도메인 당 20개, 쿠키 하나 당 4kb, 총 300개 제한
주로 두 요청이 동일한 브라우저에 들어왔는지 아닌지 판단할 때 사용된다.
예를 들면 로그인 상태 유지
1) 목적
세션관리 : 서버에 저장해야 할 정보 관리
개인화 : 사용자 선호, 테마 등의 세팅
트래킹 : 사용자 행동을 기록하고 분석하는 용도
2) 종류
세션 쿠키
Expires 혹은 Max-Age를 명시하지 않으면 클라이언트 종료 시 삭제된다.
삭제 되어도 세션 복구는 가능하다.
영속적인 쿠키
클라이언트가 닫힐 때 만료되지 않고
명시된 날짜 (Expires)나 명시된 기간(Max-Age) 이후에 만료된다.
딱 보니 둘 중에 더 빠른 날짜에 맞춰서 만료될 것임
Secure 쿠키
HTTPS 프로토콜 상에서 암호화된 요청일 경우 전송된다.
Secure일지라도 민감한 정보는 절대 쿠키에 저장하면 안된다.
3) 단점
모든 요청마다 쿠키가 함께 전송되기 때문에 성능 저하가 발생할 수 있다.
과거에는 쿠키를 사용하는 것이 유일한 방법이였지만
지금은 modern storage APIs를 사용해 정보를 저장하는 걸 권장합니다.
정보를 클라이언트 측에 저장하려면
웹 스토리지 API (localStorage, SessionStorage)와 IndexedDB를 사용하면 된다.
l 세션
클라이언트와 웹서버 간에 네트워크 연결이 지속적으로 유지되고 있는 상태를 지칭
각 클라이언트 마다 고유 ID를 부여,
세션 객체마다 저장해 둔 데이터를 이용하여 서로 다른 클라이언트 요구에 맞게 서비스 제공이 가능하다.
클라이언트 자신만의 고유 페이지를 열어 놓아서 생길 수 있는 보안성 문제 해결 용이
서버에 오브젝트 형으로 저장되며, 종료 시점을 정확히 알 수 없다.
서버의 자원을 이용하며 서버가 허용하는 한 용량 제한 있다.
l 쿠키와 세션 차이
쿠키는 클라이언트 하드에 텍스트 형식으로 저장, 정해진 개수와 용량 제한 있다.
세션은 서버에 오브젝트 형으로 저장, 서버가 용량 제한한다.
l HTTP 상태 코드
프록시 서버
클라이언트와 서버 사이에 데이터를 전달해 주는 서버
웹 캐시 기능이 있는 경우가 많고, 방식에 따라 클라이언트 IP가 서버에 노출 될 수도 있고
아닐 수도 있다.
l 과정
누군가 나무위키에 접속한다고 하면
프록시 서버는 자신이 나무위키의 대문 페이지 가지고 있는지 확인한다.
가지고 있지 않다면 외부회선을 통해 대문 페이지를 가져온다.
가지고 있다면 자신이 가진 페이지가 최신 버전인지 확인
최신이 아니면 새로 갱신된 부분 가져온다.
이론은 이렇지만 현실적으로는 사람들이 보는 웹페이지가 다르고 반복 횟수가 적고, 또한 프록시 서버를 거쳐서 두 번 통신을 하는 셈이니 큰 효과 보기 힘들다.
l 용도
이런 식으로 프록시 서버의 처음 목적은 인터넷 속도의 향상이였지만
자신의 IP를 세탁하고 IP차단 우회를 위한 도구로도 사용된다.
l 프록시를 없앨 수는 없나?
일부 인터넷 인프라가 좋지 않은 곳에서는 여전히 프록시 서버 쓰는 것이 인터넷 속도 향상에 도움되는 경우가 있기 때문에 프록시 자체를 없애버리기 힘들다.
l 원래 IP 주소는 알아낼 수 없는가?
프록시 유형 중에 Transparent Proxy의 경우는 HTTP 헤더에 원래 IP를 박기 때문에 원래 IP 알아낼 수 있으며
Annonymous Proxy 계열 부터는 원래 IP 정보 제공되지 않지만 추적이 가능하다.
국내에서는 프록시 서버에 접속한 사람의 IP를 무조건 기록해야 하므로 바로 추적당한다. 하지만 외국에 소재한 프록시 서버의 경우에는 외국의 정식 수사기관이 개입해야 추적 가능하다. 한국 경찰이 조사할 수 있는 권한이 없음. 하지만 그 나라의 법률을 어기는 한 추적이 가능하다.
HTTPS (HyperText Transfer Protocol over Secure Socket Layer / TLS / SSL / Secure)
HTTP의 보안이 강화된 버전의 프로토콜
TLS, SSL 등의 위에 HTTP를 얹어 보안된 HTTP통신을 하는 프로토콜
l 특징
1) 포트 번호 443번 사용
2) 소켓 통신에서 일반 텍스트를 이용하는 대신에, 웹 상에서 정보를 암호화하는
SSL, TLS 프로토콜을 통해 세션 데이터를 암호화한다.
TLS (Transport Layer Security) 프로토콜은 SSL에서 발전한 것이다.
두 프로토콜의 주요 목표는 기밀성, 무결성, 인증 제공이다.
3) 데이터의 적절한 보호를 보장한다.
보호의 수준은 웹 브라우저에서의 구현 정확도, 서버 소프트웨어가 지원하는
암호화 알고리즘에 달려있다.
4) 공개키 알고리즘 방식을 사용한다.
공개키는 공개키 저장소에 등록하고 개인키는 서버가 가진다.
l 필요한 이유
클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보 요청하면
서버는 요청에 응답하여 정보를 제공한다.
웹 페이지(HTML)은 텍스트이고 HTTP를 통해 이러한 텍스트 정보를 교환한다.
중요한 텍스트 정보를 주고받을 때 중간에 누군가 정보를 가로챈다면 문제가 생긴다.
다른 사람이 정보를 볼 수 없도록 암호할 필요가 있다.
l 과정
1) 서버로 데이터를 보낼 때 사용자의 데이터를 공개키로 암호화한다.
2) 서버로 전송 (데이터 가로채도 개인키 없어서 복호화 불가)
3) 서버의 개인키를 통해 복호화한다.
l 장점
데이터를 중간에 다른 사람이 Read/Write할 수 없으므로 안전하다.
l 단점
암호화 하는 과정이 웹 서버에 부하를 준다. HTTP에 비해 느려짐
HTTPS 설치 및 인증서 유지에 추가 비용 발생
인터넷 연결이 끊기면 소켓도 끊어져서 재인증을 하는데 시간이 소요된다.
l HTTP vs HTTPS
금융 정보나 메일 등 중요 정보를 주고받는 것은 HTTPS를 사용, 상관 없으면 HTTP
HTTPS는 암호화/복호화 해야하므로 HTTP에 비해 느림
360개의 고유한 캐시되지 않은 이미지를 로드 (0.62MB)
HTTP/1.1가 10초, HTTPS (HTTP/2)가 1.5초가 걸렸다.
테스트 사이트 https://www.httpvshttps.com/
SSL (Secure Socket Layer)
1. 특징
l 널리 사용되는 보안 프로토콜, 거의 모든 브라우저와 웹 서버에서 지원
l 기밀성, 무결성, 인증
l 웹 상에서 전자상거래에 적용, 암호화, 웹 서버 인증, 클라이언트 인증 등이 목표
l 모든 TCP 응용에서 사용 가능
l Socket Layer는 응용 계층과 전송 계층 사이에 존재한다.
l SSL은 HTTP(응용 계층)와 TCP(전송 계층) 사이에서 동작
2. 웹상의 상거래에서 요구사항
l Alice가 BBB라는 온라인 책방에서 책을 구매할 때
1) Alice가 거래하는 내용, 특히 지불 정보 (신용 카드 번호)를 다른 사람이 보면 x
2) 주문 내용을 침입자가 변경 못해야 함
3) 거래하는 서점이 BBB가 맞는지 확인 가능해야 함
4) BBB는 책 사는 사람이 Alice인지 확인할 수 있어야 함
3. 절차
l Handshake
Client는 Server를 인증하고 Key 계산에 필요한 값을 교환
목적 :
1) 서버 인증
2) crypto algorithms의 협상
Cipher List
암호 알고리즘 : RC4, RC2, DES, 3DES, DES40, IDEA
MAC 알고리즘 : MD5, SHA-1
암호 알고리즘 유형 : (stream of block)
해쉬 크기 : MD5 : 0 or 16 바이트, SHA-1 : 20 바이트
IV 크기 : CBC 암호화를 위한 IV크기
3) 키 설정
4) 클라이언트 인증 (선택 사항)
우리가 대화 가능한가? 암호문 리스트 RA ->
<- 인증서, 암호문 RB
Bob의 Public Key로 암호화한 것과 E 암호화 (h 해쉬(메시지, CLNT, K), K) ->
<- h 해쉬(메시지, SRVR, K)
<- 키 K와 보호된 Data
1) 암호화 알고리즘의 종류, Client Nonce (Rc) ->
2) <- 선택한 알고리즘 + 인증서 + Server Nonce (Rs)
3) Client는 인증서를 검증, Server의 공개키 추출, pre-master-secret을 생성
Server의 공개키로 암호화하여 Server로 보낸다.
4) Client와 Server는 각자 pre-master-secret와 nonces를 사용하여 암호화와 MAC Key를 계산한다.
5) Client는 모든 handshake 메시지에 MAC을 첨부하여 보낸다.
6) Server는 모든 handshake 메시지에 MAC을 첨부하여 보낸다.
5, 6단계는 협상 과정에서 중간자 공격을 막기 위해 수행
Client의 암호 알고리즘 중에 강한 알고리즘과 약한 알고리즘 있는데
중간자 공격으로 알고리즘 명단에서 강한 알고리즘을 삭제 가능
5, 6단계의 메시지는 암호화한다.
1) Nonce
Client Nonce
클라이언트 nonce는 재생 공격으로부터 클라이언트를 보호합니다.
클라이언트 nonce가 없으면 공격자는 CS의 nonce에 대한 초기 요청을 가로 채 서버가 이전에 사용한 이전 nonce로 응답 할 수 있습니다.
그런 다음 클라이언트는 이전 nonce를 사용하여 API 호출을 작성하여 공격자가 다시 가로 채고 nonce를 처음 사용할 때 실제 서버가 실제로 보낸 응답을 다시 보냅니다.
요약하자면, 재생 공격은 클라이언트가 서버의 오래된 유령과 상호 작용하게 만드는 것입니다. 클라이언트 nonce는 클라이언트가 "신선하고 살아있는"서버와 대화하고 있는지 확인할 수있게합니다.
+ Client와 Server가 Random nonce를 사용하는 이유는?
Trudy가 Alice와 Bob 사이에 교환되는 모든 메시지 복사했다면
다음날, Trudy는 Bob과 TCP연결 설정하고 전날 Alice가 보낸 메시지를 순서대로 보냄, 그러면 Bob은 Alice가 같은 주문을 다시 하는 것으로 생각한다.
이런 문제를 방지하기 위하여 Bob은 연결할 때 마다 새로운 Random nonce를 보낸다. 그러면 Trudy는 Bob의 MAC검증에서 실패
2) Pre-Master-Secreat
클라이언트와 서버는 난수와 프리 마스터 시크릿이라는 특수 번호를 교환합니다.
이 숫자는 추가 데이터와 결합되어 클라이언트 및 서버가 마스터 비밀이라고하는 공유 비밀을 작성할 수 있습니다.
마스터 시크릿은 클라이언트와 서버에서 해싱에 사용되는 세션 키인 쓰기 MAC 시크릿 과 암호화에 사용되는 세션 키인 쓰기 키를 생성하는 데 사용됩니다.
사전 마스터 비밀의 요점은
TLS 암호화 방식 군 사이에 큰 일관성을 제공하는 것입니다.
SSL / TLS에서 클라이언트와 서버는 암호화를 위한
공동Key, 메시지 인증 코드 생성을 위한 공동Key를 공유해야 한다.
하지만 클라이언트는 키를 서버로 직접 보내지 않고
사전 마스터 시크릿을 보내고 키를 생성한다.
그 이유는 클라이언트가 RSA 암호가 아닌 예를 들어 타원 곡선 Diffle-Hellman을 사용하면 출력이 48바이트보다 길거나 짧을 수 있으며, 제대로 분배되지 않을 수 있다. 이런 이유로 마스터 시크릿을 일관된 형식으로 만드는 것이 좋다.
키 교환 측과 암호화 측을 분리할 수 있다. 마스터 키를 난수로 만드는 것이 좋다.
쉽게 말하자면 선택한 암호 제품군에 따라 키 생성/합의 방법이 달라지기 때문에
3) Mater Secret
4) Private Key
5) Shared Secret / Session Key
세션 키를 K에서 파생 된 키라고 한다.
이것은 암호화 키, 무결성 보호 키, 암호의 IV등 일 수 있다.
l Key 계산
Client는 Server는 비밀값을 사용하여 키를 계산
한 개의 키로 모든 암호화를 하는 것은 나쁜 방법
MAC에서 사용하는 키와 암호화 키는 다른 것을 사용한다.
4개의 키와 2 IVs
Kc = Client의 암호화 키 (대칭키)
Mc = Client의 MAC 키 (비밀값)
Ks = Sever으 암호화 키 (대칭키)
Ms = Server의 MAC 키 (비밀값)
2 IVs = Client와 Server가 사용할 IV값
Key들은 다음의 값을 사용하여 해쉬 함수의 출력값을 짤라서 사용
Client의 nonce(RA), Server의 nonce(RB), master secret(S)
l 데이터 전송
데이터는 레코드로 쪼개서 MAC을 첨부하고 암호화하여 전송
l 연결 종료
연결 종료하기 위한 특별 메시지를 보낸다.
l SSL 인증
Alice는 Bob을 인증하지면 Bob은 Alice를 인증하지 못한다.
원하면 상호 인증도 가능하다.
Bob은 메시지2에 Client의 인증서를 요청할 수도 있다.
TLS (Transport Layer Security)
인터넷에서 정보를 암호화해서 송수신하는 프로토콜, SSL3.0에 기반
l 작동 방법
서로 자신을 신뢰할 수 있음을 알리기 위해 전자서명이 포함된 인증서 사용
도청을 방지하기 위해 통신 내용 암호화
<Handsake>
1) 클라이언트는 가능한 TLS버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보를
ClientHello 메시지에 담아 보낸다.
2) 메시지를 받은 서버는 사용하기로 한 TLS버전, 세션 식별자, 암호 설정 등 정보를
ServerHello 메시지에 담아 보낸다.
3) 서버가 클라이언트에게 서버의 인증서가 포함된 Certificate 메시지 보낸다.
(인증서는 인증 기관(CA)에서 받은 것)
전송이 끝나면 ServerHelloDone 메시지를 보내 끝났음을 알린다.
4) 클라이언트는 서버의 인증서를 검증 (유효 기간, 서버의 인증서가 맞는지 등)
5) 인증서가 맞다면 클라이언트는 임의의 pre-mater secret을 생성
서버가 보낸 인증서에 포함된 공개 키를 사용해 암호화한다.
암호화된 pre-master secret을 ClientKeyExchange메시지에 포함시켜 전송
6) 서버는 전송받는 정보 복호화하여 pre-master secret을 알아낸 뒤,
이 정보를 사용해 master secret을 생성한다. (클라이언트도 마찬가지로 생성)
master secret에서 세션 키를 생성 (세션 키는 통신을 암호화하는데 사용)
7) 서버와 클라이언트는 각자 동일한 세션 키를 가지고 있으며,
이를 이용해 대칭 키 암호를 사용하는 통신이 가능하다.
서로에게 ChangeCiperSpec 메시지를 보내 앞으로의 모든 통신은 세션 키를
이용해 암호화해서 보낼 것을 알려준 뒤,
Finished 메시지 보내 각자의 Handshaking 과정이 끝났음을 알린다.
8) 이제 서버, 클라이언트 간에 보안 통신이 구성된다.
경우에 따라 서버에서 클라이언트의 인증서를 요구하기도 함
l 단점
일반 통신에 비해 큰 패킷을 사용하는 암호화 통신인 만큼
속도상의 손해가 발생한다.
플래시, 큰 이미지가 많은 사이트에서 TLS 사용하면 매우 느림
l HTTP를 HTTPS로
Http로 연결했을 경우에도 https로 redirect 하도록 설정하는 것이 필요
l SSL/TLS 보안 강화
최신 버전의 TLS를 사용
강력한 알고리즘 사용
l HSTS (HTTP Strict Transport Security)
중간자 공격 (Man in the middle attack)의 일종인 SSL strip 공격을 방지
HTTP 헤더에 Strict-Transprot Security가 있으면
브라우저는 무조건 HTTPS로만 연결하도록 하여 공격을 방지한다.
1) max-age = delta-second : 브라우저에서 delta-second로 지정된 시간만큼
HTTPS를 사용하라는 의미이다. 개발단계에서는 작게, 안정화되면 크게
2) includeSubdomains : HSTS를 서브 도메인에도 적용
3) preload : 브라우저가 해당 사이트를 HSTS 적용 preload list에 추가
l SSL Strip 공격이란?
SSL을 Strip(벗기다)해서 강제로 HTTP통신을 유도하는 기법
SSL이 적용된 경우에 MITM(중간자 공격)을 해도 내용을 해독할 수 없기 때문에 MITM이 불가능하다.
하지만 최초 서버와 세션 연결 시 HTTPS를 강제로 HTTP 통신을 하게 끔 만든다면 MITM 공격이 가능하다.
서버의 응답을 가로채서 모든 주소를 HTTPS에서 HTTP로 변경한 후 클라이언트에게 전송하여 Client와 공격자 간에는 HTTP통신, 공격자와 서버 간에는 HTTPS통신을 맺는 것
그런데 HSTS의 정책이 Hostname을 기반으로 적용된다는 점을 이용하여
HSTS를 우회하는 SSL Strip+ 가 있다.
l SSL Strip+
HSTS의 정책이 Hostname을 기반으로 적용된다는 점을 이용하여 HSTS를 우회하는 기법,
includeSubDomain 옵션이 누락된 경우에만 가능하다.
Cleint가 DNS 요청 시 DNS Spoofing을 통해 유사한 SubDomain을 반환한다.
해당 SubDomain은 HSTS정책이 적용되지 않기 때문에 Client는 변조된 HTTP로 접속한다. 그 이후로는 같다.
l DNS Spoofing
도메인 네임 시스템에서 전달되는 IP주소를 변조하거나 도메인 네임 시스템의 서버를 장악하여
사용자가 의도하지 않은 주소로 접속하게 만드는 공격방법이다.
이것도 중간자 공격을 통해 사용자의 질의 내용을 수정하여 도메인 네임 서버에 전송하여
의도하지 않은 주소로 보내는 것이다.
l SSL vs TLS 차이는?
TLS는 SSL 3.0이 가지고 있는 대부분의 취약점을 해결하였다.
SSL 3.0은 충분히 안전하지 않아서 지원이 끝남.
어떻게 보면 SSL 4.0이 TLS라고 생각하면 된다.
l 버전
1) TLS 1.0
1990년도에 SSL 3.0의 업그레이드 버전으로 공개
SSL 3.0이 가지고 있는 대부분의 취약점을 해결하였다.
기본적으로 SHA-1 알고리즘 사용, 보안을 위해 SHA-256도 지원하기도
2) TLS 1.1
2006년 4월 공개, 암호 블록 체인 공격에 대한 방어, IANA등록 파라메터 지원 추가
너무 오래되어 2020년 쯤에는 대부분 브라우저에서 지원 중단 예정
3) TLS 1.2
2008년 8월 공개, 취약한 SHA-1 해싱 알고리즘을 버리고 SHA-256만을 사용하도록 변경되었다. 나무위키, 네이버 등 포털 사이트에서 지원
4) TLS 1.3
2018년 8월 게시, 서버에서 인증서를 암호화하여 전달하도록 개선,
최초 연결시에 암호화 통신을 개시하는 절차를 간소화하여 성능 향상
오래된 암호화 기술 폐기 등
TLS 1.2도 충분히 안전하므로 당장 업그레이드가 필요한 것은 아니지만
확장 기능인 SNI 필드 암호화 확장 규격까지 합치면
클라이언트에서 서버로 보내는 도메인이 평문으로 전송되는 부분이 아예
없어지기 때문에 인터넷 검열에 대응하는 사이트는 업데이트를 서두를 것으로 보인다.
성능 면에서는 HTTP/2의 보급으로 예전처럼 웹페이지 열 때마다 새 연결을 맺지 않고 한 연결을 맺고 계속 쓰기 때문에, 최초 연결에서 절차가 간소화 된다고 하더라도 성능에서 큰 차이 없을 듯 하다.
l 문제점
1) TLS에서 신원을 확인하는 데 인증서가 사용된다.
인증서의 신뢰성은 인증 기관 (CA, Certification Authority)에 의해 결정되므로
CA가 제대로 확인된 인증서 발급 안 하면 신뢰할 수 없을 것이다.
예를 들어 namu.wiki 가 아닌 narnu.wiki를 만들고 발급 비용만 내면 아무나 인증서 발급받을 수 있다. 도메인 소유자와 인증서 신청자가 같기 때문에 가능함
이 피싱 사이트 접속한 사람들은 HTTPS 연결이 되어있기 때문에 보안이 지켜질 것으로 생각함
이 문제를 해결하기 위해 나온 것이 EV-SSL이다.
EV-SSL은 공신력 있는 CA에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 그 인증서를 쓰는 웹페이지에 접속하면 주소창에 녹색 표시 뜨며 EV-SSL에 연결 되었음을 알린다.
2) TLS는 망연결에서 보안을 책임진다.
만약 연결된 단말기가 해킹당한 경우면 소용없음
3) 부하가 크다
평문 통신에 비해 암호화 과정을 거쳐야 하기 때문에 대규모 웹 사이트에서
HTTPS를 쉽게 적용하지 못하는 경우가 있다.
이를 이용해 DDoS라도 시도하면 암호화 과정 때문에 부하 걸려서 서버 죽을 수도 있다. 따라서 프론트 서버를 더 늘리거나 DDoS 방어 서비스 이용
4) 파일을 지우면 먹통
이 파일은 레지스트리 내부에 저장되어 있는데, crypt32를 지우면 인터넷이 완전히 먹통이 된다.
l OpenSSL
TLS와 SSL의 오픈 소스 구현 판이다. C언어로 작성된 중심 라이브러리 안에는
기본적인 암호화 기능, 여러 유틸 함수이 구현됨, 거의 모든 OS상에서 사용 가능
l WebtoB의 Wbssl
WebtoB의 OpenSSL 라이브러리이다.
서버 이름 표시 SNI (Server Name Indication)
1) 문제의 배경
SSL/TLS가 HTTP보다 먼저 수행되므로 브라우저가 Host Header를 보내기 전에
SSL Handshaking이 이루어지고 웹 서버는 첫 번째 SSL 가상 호스트에 설정된 서버 인증서를 전송합니다.
그래서 SSL/TLS기반으로 여러 개의 가상 호스트를 설정했을 경우
브라우저에서 SSL 인증서 검증시 인증서와 HostName 다르다는 에러 발생 가능
쉽게 말하자면
서버내에 여러 사이트가 운영되는 환경에서는각각의 인증서 파일이 서로 다르다.
SSL 연결 초기화 과정에서 서버는 어떤 인증서를 보내야 할지 확인하기 어려울 수 있다.
2) 문제 해결
SNI는 TLS 프로토콜의 확장 표준이다. SNI 필드는 서버의 어떤 도메인이 브라우저에서 Handshaking 과정에서 연결되는지 나타낸다.
이 필드를이용하여 서버는 여러 개의 도메인 인증서를 구분하여 처리할 수 있다.
동일 IP 주소의 단일 서버에서 여러 DNS 호스트 이름을 호스팅할 수 있다.
3) SNI 필드 차단 방식 원리
클라이언트가 요청하는 서버의 도메인이 Plain Text로 나타나기 때문에 차단이 가능
4) SNI 차단 우회
VPN, Encrypted SNI, TLS 1, 3 사용 등의 방법이 있다
REST와 RESTful의 개념
※ REST (Representational State Transfer) 대표적인 상태 전달
WWW과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에
웹의 장점을 최대로 활용할 수 있는 아키텍처 스타일이다.
REST는 네트워크 상에서 클라이언트와 서버 사이의 통신 방식 중 하나이다.
l 개념
HTTP URI를 통해 자원을 명시하고, HTTP Method(Get, Post, Put, Delete)를 통해
자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
CRUD는 Create, Read, Update, Delete다.
자원 기반의 구조 (ROA, Resource Oriented Architecture) 설계의 중심에
Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처
웹 사이트의 이미지, 텍스트, DB 내용 등 모든 자원에 고유 ID인 HTTP URI 부여
l 장점
여러 서비스 디자인에서 생길 수 있는 문제 최소화
하이퍼 미디어 API의 기본을 충실히 지키면서 범용성 보장
HTTP 프로토콜 표준을 최대한 활용하여 여러 추가 장점을 함께 가져갈 수 있다.
l 단점
브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URI보다
Header값이 더 어렵다.
구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 있다. (Put, Delete, PushState)
l 필요한 이유
어플리케이션 분리 및 통합
다양한 클라이언트 등장
최근 서버 프로그램은 다양한 브라우저와 모바일 디바이스에서도 통신 되어야 함
l 구성
1) 자원 : URI
모든 자원에 고유 ID인 HTTP URI존재, 이것은 Server에 존재
Client는 URI 이용해서 자원 지정하고 해당 자원의 상태에 대한 조작을 요청
2) 행위 : HTTP Method
HTTP 프로토콜의 Method 사용
HTTP 프로토콜은 GET, POST, DELETE, HEAD 와 같은 메소드 제공
3) 표현
Client가 자원의 상태정보를 조작을 요청하면 Server는 적절한 응답을 보낸다.
REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 표현이 가능하다.
JSON 또는 XML을 통해 데이터 주고 받는 것이 일반적
l 특징
1) Server-Client 서버 클라이언트 구조
2) Stateless 무상태
3) Cacheable 캐시 처리 가능
4) Layered System 계층화
5) Code-On-Demand (Optional)
6) Uniform Interface 인터페이스 일관성
※ REST API
REST 기반으로 서비스 API를 구현한 것
최근 OpenAPI, 마이크로 서비스등을 제공하는 업체 대부분은 REST API 제공
l 특징
1) 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성, 재사용성 높여
높은 유지보수, 운용을 편리하게 할 수 있다.
2) REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로
클라이언트 서버를 구현할 수 있다.
REST API를 제작하면 델파이 클라이언트, 자바, C#, 웹 등으로 클라이언트 제작 가능
l 설계 규칙
1) RUI는 정보의 자원을 표현
2) 자원에 대한 행위는 HTTP Method로 표현
3) / 구분자는 계층 관계를 나타내는데 사용한다.
4) URI 마지막 문자로 /를 포함하지 않는다.
5) -은 URI 가독성 높이는데 사용
6) _은 URI에 사용하지 않는다.
7) URI 경로에는 소문자가 적합
8) 파일확장자는 URI에 포함하지 않는다.
9) id는 하나의 특정 자원을 나타내는 고유값이다.
※ RESTful
REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어로
REST 원리를 따르는 시스템을 RESTful 이라고 한다.
REST를 REST답게 쓰기 위한 방법
l 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
성능 향상 보다는 일관성 있는 컨벤션을 통한 API의 이해도 및 호환성 높이기
l RESTful 하지 못한 경우
CRUD 기능을 모두 POST로만 처리하는 API
route에 resource, id 외의 정보가 들어가는 경우
(/students/updateName)
SSH (Secure Shell Protocol)
컴퓨터가 인터넷과 같은 Public Network를 통해 서로 통신을 할 때
보안적으로 안전하게 통신하기 위해 사용되는 프로토콜
l 용도
1) 데이터 전송
원격 저장소인 Github에 푸쉬할 때 사용됨
2) 원격 제어
AWS같은 클라우드 서비스의 인스턴스 서버에 접속하여 명령을 내리기 위해서도
SSH를 통한 접속을 한다.
l 다른 통신을 위한 프로토콜도 있는데?
SSH를 사용하는 이유는 보안 때문이다.
먼저 보안적으로 훨씬 안전한 채널을 구성한 뒤 정보를 교환하기 때문
l 암호화
PKI을 사용한다.
'취업 준비' 카테고리의 다른 글
| 데이터베이스 (DataBase) (0) | 2019.10.06 |
|---|---|
| 운영체제 (Operating System) (0) | 2019.10.05 |
| 컴퓨터 공학 전공 지식 요약 모음집 (0) | 2019.10.05 |