Tech Log 🛠️

1. 서류

- 대략 50명 정도가 지원했다고 추측했는 데 면접장에는 3명 정도가 와있었다. 물서류는 아닌듯

2. 인성검사

- 잡다같은 인성검사가 아니라 문항들이 굉장히 특이했다. 최대한 솔직하면서도 함정에 안빠질려고 했다. 떨어진 사람 몇몇 있었음

3. 1차 면접

- 처음 면접이라 굉장히 긴장을 했는데, 실무진분들이 최대한 편하게 해주기 위해 노력하셨다. 그래도 꽁꽁 얼어붙어서 면접 봤던 기억이 난다. 

질문 자체는 직무에 대해 얼마나 알고 있는지 (기술x), 지원서 기반 질문

4. 2차 면접

- 분위기는 1차 면접과 비슷했다. 질문들도 무난무난 했던 편

0. 지원 직무

- kt ds 클라우드/인프라 엔지니어링

1. 서류

- 2023년 서류는 굉장히 빡셌다고 들었는데 올해 상반기 서류는 굉장히 널널했다.

2. 인적성

- 지쌋이나 skct 같이 유형을 미리 익히고 공부를 해야 하는것이 아닌, 정말 그냥 풀어도 될 정도로 난이도가 평이했다.

문제는 총 80문제로 기억하는 데 컷은 체감상 60개 정도

오히려 문제 정답률은 일정 수준만 보고 인성 검사를 많이 반영한 거 같기도 했다.

2.5 피티 면접 준비

- 일요일에 따로 피티 면접을 준비하는 시간이 주어진다. 주제는 총 3가지인데 그 중 하나 골라서 1페이지 분량의 피티 자료 만들면 됨

3. 실무 면접

- 온라인으로 진행했으며, 한 타임에 8명 정도가 각기 다른 줌 면접방에 들어갔다. 한 방에 면접관분들이 4명 정도 계신데 다들 친절하셨다. 일단 처음으로 피티 발표하고 QnA를 받았다. 근데 생각보다 질문이 평이했고 그 기술 자체에 크게 관심이 없어보이셨다. 

피티 면접이 끝나면 이력서/ 자소서 기반의 질문을 받는다. 난이도는 평이한 편! 인상 깊었던 것은 이력서에 첨부된 내 이력서와 블로그를 보시고 그것을 기반으로 질문을 많이 주셨다.

4. 임원 면접

- 다대다로 진행되며 난 4대3 으로 봤다. 공통질문과 개인질문을 반반 비율로 받았다. 공통질문은 그냥 형식적인 입사 후 포부, 무슨 일 하고 싶은지 이런 질문들

임원 면접을 굉장히 잘 봤다고 생각했는데 떨어져서 많이 답답했다. 면까몰은 진리인듯

*혹시 궁금한 점 있으시면 아는 선에서 최대한 답변 드리겠습니다.

1. 쿠키 인증 방식

쿠키란 서버가 클라이언트의 브라우저에 key value 형태로 저장해놓는 작은 기록파일이다.
쿠키를 이용하여서 간단한 로그인을 구현할 수 있다.
 

쿠키 로그인 인증 방식
 

 
클라이언트에서는 로그인이 필요한 요청을 할때마다 다음과 같이 쿠키에 id, pw 정보를 담아서 전송한다.
위와 같은 작업을 수행하기 위에서는 이미 브라우저에서 로그인이 진행된 후 유저 정보가 쿠키에 들어있어야한다.
 
하지만 쿠키 인증 방식은 여러 문제가 있다.
1. 쿠키값 유효성 검증이 힘들다. (조작 가능성이 있다.)
2. 중간에 탈취해서 id,pw 정보를 확인할 수 있다.
3. 서버에서 매번 인증을 수행해야한다.
4. 브라우저마다 쿠키 형식이 통일되어 있지 않아서 브라우저 간 공유가 어렵다.
 
따라서 쿠키만 이용한 인증 방식의 한계를 보완하기 위해 세션을 사용한 인증 방식이 나오게 되었다.
 

2. 세션 인증 방식

세션은 사용자의 연결을 하나의 상태(세션)으로 유지시키는 기술을 말한다.
 

세션 로그인 인증 방식

쿠키는 매번 id,pw 같은 민감 정보를 전송해야했다면, 세션은 서버의 세션 저장소에 세션 정보를 저장함으로써 보완을 강화했다.
클라이언트는 인증이 필요한 요청을 필요할 때 쿠키에 세션 인증 정보를 함께 보내고 서버는 이를 세션 저장소의 내용과 비교해서 인증 여부를 판단한다.
(마치 매표소에서 티켓의 절반을 떼서 손님이랑 나눠가지는 원리와 비슷하다.)
이렇게 함으로써 인증 요청 시에 민감 정보를 네트워크 상에 노출 시키는 것을 예방할 수 있다.
 
하지만 세션 방식도 여러가지 문제를 안고 있다.
1. 서버가 재부팅되면 세션 저장소가 초기화된다.
2. 스케일 아웃 방식의 확장이 어렵다. -> 모든 서버에 세션 정보를 동기화 시켜야한다.
3. 사용자의 수가 많아지면 관리해야하는 세션 정보가 많아져서 서버의 부담이 된다. -> 무상태(stateless) 위반
4. 세션 인증 정보 탈취의 위험이 있다.
 

3. JWT 인증 방식 

JWT(Json Web Token) 방식은 토큰 기반의 인증 방식이다. 이 방식을 통해 그 동안의 인증 방식에서 나왔던 문제들을 어느정도 개선할 수 있다.
 

JWT 로그인 인증 방식

JWT 토큰 구조는 크게 3가지로 구분된다.
 
header
키값, 토큰 유형, 암호화 알고리즘 같은 정보들을 담고 있다.
 
payload
클레임(claim)이라고 하는 유저의 토큰 인증 정보를 key/value 형태로 담고 있다.
JWT 스펙에서는 표준 claim 목록을 다음과 같이 정의하고 있다. (권장 사항일 뿐 꼭 지킬 필요는 없을 것 같다)
 
iss (Issuer, 토큰 발급자): . 누가 토큰을 발급(생성)했는지
sub (Subject, 토큰 주제): 주제에 대한 설명을 나타냅니다.
aud (Audience, 토큰 수신자): 누구에게 토큰이 전달되는 가
exp (Expiration, 만료 시간): 언제 토큰이 만료되는지
nbf (Not Before): 정의된 시간 이후에 토큰이 활성
iat (Issued At, 토큰 발급 시간): 언제 토큰이 발급되었는지
jti (JWT ID, 토큰 식별자): 토큰의 고유 식별자
 
signature
JWT에서 가장 민감한 부분이다. 해당 값으로 토큰의 유효성을 판별하며 이때 사용되는 시크릿 값을 유출시키지 않는 것이 매우 중요하다.
시크니처는 헤더+페이로드+시크릿 값을 암호화 알고리즘으로 암호화하여서 만들어진다.
따라서 시크릿 값이 조금이라도 다르다면 토큰 내용은 완전 변하게 되어서 인증이 불가능해진다.
 
여기서 주의할 점은 헤더와 페이로드는 암호화가 아닌 base64 방식으로 인코딩 되는 방식이기 때문에 제3자도 토큰만으로도 해당 값들을 열람할 수 있다. 따라서 식별자를 제외한 민감한 정보들을 최대한 넣지 말아야한다!
 
JWT는 클라이언트에게 토큰을 주는 방식이기 때문에 만약 토큰이 탈취 당한다면 서버에서 딱히 할 수 있는 것이 없다.
이 점을 보완하기 위해 리프레시 토큰을 이용해서 기존 토큰의 유효 시간을 짧게 가져가고 새로운 토큰을 지속해서 발급해주는 방식을 사용하기도 한다.

하지만 일정 시간 동안은 탈취된 토큰이 사용될 수 있는 것이기 때문에 근본적인 해결법은 아니다. 그래서 은행 같이 보안에 굉장히 민감한 곳에서는 여러 외부 프로그램을 사용해서 보안을 강화한다.
 

1. 로드 밸런서란?

어플리케이션은 여러 사용자의 요청들을 동시에 처리하고 안정적인 서비스를 제공해주어야한다. 

물론 한 대의 서버로 성능을 계속 키워서 어느 정도는 커버(Scale-up)할 수 있겠지만, 이 방식은 얼마 안가서 한계를 만나게 된다.

따라서 여러 대의 서버를 둬서 요청 부하를 분산하도록 하는 것(Scale-out)이 로드 밸런싱이고 이 역할을 하는게 로드 밸런서이다.

로드 밸런서는 사용자와 서버 사이에 위치하며 모든 리소스 서버가 최적의 성능을 내도록 부하를 분산한다.

2. 로드 밸런싱 사용의 이점

가용성

서버 장애 또는 부하로 인한 딜레이를 로드 밸런싱을 통해 사전에 방지함으로써 어플리케이션의 가용성을 증가시킨다.

다음과 같은 작업을 간편하게 수행할 수 있다.

• 애플리케이션 가동 중지 없이 애플리케이션 서버 유지 관리 또는 업그레이드 실행
• 백업 사이트에 자동 재해 복구 제공
• 상태 확인을 수행하고 가동 중지를 유발할 수 있는 문제 방지

확장성

어플리케이션의 규모나 트래픽이 증가하더라도 로드 밸런싱을 통해 트래픽들을 지능적으로 여러 서버에 분산할 수 있다.

따라서 확장이 용이해진다.

• 한 서버에서 트래픽 병목 현상 방지
• 필요한 경우 다른 서버를 추가하거나 제거할 수 있도록 애플리케이션 트래픽을 예측
• 안심하고 조정할 수 있도록 시스템에 중복성을 추가

보안성

디도스같은 악성 트래픽 공격을 로드 밸런싱을 통해 피해를 최소화 할 수 있다.

악성 트래픽을 여러 서버로 분산시키거나 방화벽을 통해 사전 차단한다.

• 트래픽 모니터링 및 악성 콘텐츠 차단
• 공격 트래픽을 여러 백엔드 서버로 자동으로 리디렉션하여 영향 최소화
• 추가 보안을 위해 네트워크 방화벽 그룹을 통해 트래픽 라우팅

성능 향상

지능적인 부하 분산을 통해 어플리케이션 응답 성능을 향상시킨다.

• 서버 간에 로드를 균등하게 배포하여 애플리케이션 성능 향상
• 클라이언트 요청을 지리적으로 더 가까운 서버로 리디렉션하여 지연 시간 단축
• 물리적 및 가상 컴퓨팅 리소스의 신뢰성 및 성능 보장

참고 : https://aws.amazon.com/what-is/load-balancing/?nc1=h_ls

3. 로드 밸런서의 종류

부하 분산에는 L4 , L7 로드 밸런서가 가장 많이 사용된다.

여기서 L4는 OSI7 계층의 통신 계층, L7은 어플리케이션 계층이다.

따라서 다른 말로 네트워크 로드 밸런서 , 어플리케이션 로드 밸런서라고도 한다.

L4 로드 밸런서

전송 계층의 IP, PORT 같은 정보들을 사용하여 부하를 분산한다.

패킷이나 쿠키같은 데이터들을 분석할 필요없이 비교적 단순하게 작동하기 때문에 L7 로드 밸런서에 비해 빠르고 가볍다는 장점이 있다.

*Client IP와 서버사이에 서버로 들어오는 트래픽은 로드 밸런서를 통하고 나가는 트래픽은 Client IP와 직접 통신한다.

L7 로드 밸런서

애플리케이션 계층(HTTP, FTP, SMTP)에서 로드를 분산하기 때문에 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. ex) 결제 서버, 회원 가입 서버

L7 로드 밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있다.

하지만 기능이 많은 대신 그만큼 자원 소모가 크다는 단점이 있다.

*Client IP와 서버사이에 들어오고 나가는 트래픽이 모두 로드 밸런서와 통신한다.

4. 로드 밸런서 알고리즘

대표적인 알고리즘 딱 3개개만!

라운드 로빈(Round Robin)

요청 받은 순서대로 로드 밸런싱 서버에 할당한다. 

서버들의 성능이 비슷하고 처리 시간이 짧은 경우 유리하다.

가중 라운드 로빈(Weighted Round Robin)

서버간 성능이 다른 경우 서버에 가중치를 부여하여서 부하를 분산한다.

최소 연결 방식(Least Connection)

연결 상태가 가장 적은 서버에 우선적으로 부하를 분산한다. 

세션이 자주 길어지거나 분배된 트래픽들이 일정하지 않을 경우 유리하다.

DNS 라운드 로빈

로드 밸런서를 활용하지 않고 로드 밸런싱을 하는 방법이다. 

DNS 라운드 로빈 방식을 사용하면 네임서버는 사용자가 입력한 도메인에 해당하는 여러 IP 정보들을 응답한다.

클라이언트는 여러 IP 정보중에서 하나를 선택할 수 있으며, 결론적으로 여러 IP로 트래픽이 분산된다.

이 방식은 웹 서버들이 지리적으로 분산되어 있어 부하 분산이 어렵거나 가벼운 구현 방식이 필요할 때 적합하다.

하지만 캐싱으로 인해서 특정 IP에 트래픽이 몰릴 수 있고, 헬스 체크를 하지 못해서 요청한 IP로 연결이 거부될 수 있다는 단점이 있다.

1. DNS란?

도메인은 인터넷에서 사용하는 주소로 비유할 수 있다.

원래 숫자로 된 긴 IP 주소를 사용하지만 실제로 사람들이 이 주소를 기억하기는 어렵다. 그래서 인터넷 상에서 주어진 위치를 쉽게 찾기 위해서 도메인이 개발되었고, 자연스레 도메인을 IP 주소로 변환해주는 도메인 네임 시스템(Domain Name System, 이하 DNS)이 개발되었다.

DNS를 통하여 사용자들은 도메인 이름만 가지고도 쉽게 웹 사이트에 접속할 수 있게 해주며, 설령 주소가 바뀐다고 한들 도메인 이름을 바뀌지 않는다.

이러한 DNS 시스템은 세계적으로 일관된 규칙을 가지며 계층 구조를 가지는 분산 데이터베이스 구조이다.

2. DNS 구성 요소

도메인 네임 스페이스

DNS는 거대한 분산 네이밍 시스템이며, 도메인 네임 스페이스는 이러한 DNS가 저장/관리하는 계층적 구조이다.

최상위에 루트 서버가 존재하고 그 아래로 인터넷에 연결된 노드들이 연속해서 이어진 계층 구조이다.

1. 루트 DNS 서버

TLD DNS 서버의 IP주소를 저장하고 안내한다.

DNS 매핑 과정의 첫 단계이다.

2. TLD 서버

도메인 등록 기관이 관리하며 SLD DNS 서버의 IP주소를 저장하고 안내한다. 

호스트 이름의 마지막 부분을 호스팅한다.

ex) example.com 의 "com"

3. SLD 서버(권한 있는 네임 서버)

실제 개인 도메인과 IP 주소의 관계가 기록된다.

네임 서버 쿼리의 종착점이다. 권한있는 이름 서버가 요청한 레코드에 대한 액세스 권한이 있다면, 요청한 호스트 이름의 IP 주소를 초기 요청을 한 DNS 리커서에게 돌려 보낸다.

4. Resolver , Recursive ,Recurser

쿼리를 통해 IP 주소를 알아낸다.

네임 서버

문자열로 표현된 도메인 이름을 실제 컴퓨터가 통신할 때 쓰는 IP 주소로 변환 시킬 때 사용한다.

네임 서버는 도메인 네임 스페이스의 트리 구조에 대한 정보를 가지고 있다.

리졸버 

DNS 클라이언트의 요청을 네임 서버로 전달하고 네임 서버로부터 정보를 받아 클라이언트에게 제공한다.

먼저 하나의 네임 서버에게 요청을 전달하고 해당 네임 서버에 정보가 없으면 다른 네임 서버에게 요청을 보낸다.

리졸버의 모든 기능을 클라이언트에 구현하는 것은 무리가 있으므로 주로 DNS 서버에서 구현하고, 클라이언트는 단순한 리졸버 기능(리졸버 루틴)만 구현하게끔 한다.

4. 쿼리

재귀적 쿼리(질의)

일반적인 네임 서버 방식이며, 클라이언트(리커서, 리졸버)에게 최종 결과값을 반환한다.

반복적 쿼리(질의)

자신이 직접 관리하지 않는 질의 요청이 올 경우 질의 응답이 가능한 NS 목록을 응답한다.

Root 네임 서버는 무조건 반복적 방식이고 TLD는 일부만 반복적 방식을 사용한다.

5. DNS 동작 방식

1. 사용자가 브라우저에 주소를 입력한다.

2. 브라우저는 DNS 서버에 요청하기 전에 캐시를 확인하여 정보를 찾는다.

3. 만약 정보를 찾기 못하였다면 root 서버에 반복적 질의를 보낸다.

도메인에 대한 정보를 저장하는 최상위 도메인(TLD) DNS 서버(예: .com 또는 .net)의 주소로 확인자에 응답한다.

ex) example.com을 검색할 경우의 요청은 .com TLD 서버를 응답 받음

4. SLD 네임 서버로부터 최종적으로 IP 주소를 응답받는다.

5. 브라우저는 응답 받은 IP 정보로 요청을 전송하고 웹 페이지를 띄울 수 있다.

6. 해당 도메인에 해당하는 정보는 일정 시간 캐싱된다.

모니터링과 관찰 가능성

모니터링은 시스템이 제대로 동작하는 지 확인하기 위해 로그 지표 추적을 수집하고 분석한다.

관찰가능성은 시스템이 빠르게 동작하지 않는 이유를 알 수 있다.

관찰 가능성이 모니터링 포괄적인 의미이다.

AWS 관찰가능성 3가지 필라(phillar) - 로그, 지표, 추적

모니터링에서도 가장 중요한 요소이다.

클라우드 워치에서는 3가지 필라를 단일 플랫폼에서 확인가능할 수 있으며, 전체 스택을 모니터링 하고 경보 로그 및 이벤트 데이터를 사용하여 자동화된 조치를 취하고 평균해결시간(MTTR) 단축할 수 있다.

AWS 관찰가능성을 AWS 네이티브 서비스 혹은 오픈소스 관리형 서비스에서 확인 할 수 있다.

클라우드 워치 동작 방식

클라우드 워치의 동작 방식은 단계 별로 구분된다.

1. 수집 모니터링 행동 분석

수집은 로그 지표 이벤트 형태로 모니터링 및 운영 데이터 수집

2. 모니터링 자동하된 데시보드로 시각화

AWS리소스 어플리케이션 및 서비스를 통합적으로 볼 수 있다.

3. 행동에서는 지정한 지표의 임계값을 기반으로 경보를 생성하거나 기계 학습 알고리즘을 기반으로 비정상 적인 지표 동작을 감시할 수 있다. 트리거로 자동동작 , 오토스케일링 -> MTTR 단축

4. 분석에서는 심층적으로 분석하여 성능 개선한다.

아마존 클라우드 워치는 기본적으로 지표 저장소이다.

정렬된 시계열 집합으로 검색 가능하며, 네임 스페이스 별로 격리를 제공하기 때문에 서로 격리되어있어서 다른 어플의 지표가 실수로 동일한 통계로 집계되지는 않는다.

더 짧은 기간으로 게시된 데이터 포인트는 장기 보관을 위해 집계

ex) 1분 세분화 데이터를 표준 분해능으로 저장 , 1분 미안은 1초 세분화 데이터를 고분해능으로 저장

-> AWS 서비스에 의해 생성되는 지표는 기본적으로 표준 분해능 (1분 미만은 고분해능 사용자 지표)

고분해능은 어플리케이션의 단기활동을 보다 즉각적으로 관찰 가능

백분위 수는 지표 데이터의 분포를 정확하게 이해하는데 도움

로그 스트림

로그 이벤트의 동일한 소스를 묶어서 로그 스트림을 이룬다. 로그 스트림 수에는 제한이 없다.

로그 저장 비용이 불필요하게 발생할 수 있기 때문에 로그 그룹의 성격에 맞게 적절한 로그 보존 설정이 필요하다.

에이전트는 에이전트 , 지표 , 로그 , 추적이 있는 JSON 파일을 통해 확인 가능하다.

다양한 운영체제에 설치 가능, 운영 체제 전반에 걸쳐 내부 시스템 수준의 지표 수집 가능하며,

AWS 가 관리하지 않는 서버 뿐만 아니라 하이브리드 환경의 서버도 포함한다.

statsD collected 프로토콜을 사용하여 어플리케이션 또는 사용자 지정 지표를 검색할 수 있다.

지표 섹션은 클라우드 워치에서 게시할 사용자 지정 지표를 지정할 수 있다.

인사이트

클라우드 워치 로그 인사이트는 통합된 인터렉티브 로그 분석, 로그데이터를 대화식으로 검색하고 분석할 수 있다.

잠재적인 원인을 식별하고 배포된 수정사항을 확인할 수 있다.

컨트리뷰터 인사이트

로그데이터 분석 기고자 데이터를 표시하는 시계열 생성

상위 n개의 기여자 총 고유 기여자 사용량 데이터 

잘못된 호스트 찾기 , 사용량이 가장 많은 네트워크 식별 , 가장 많은 오류를 내는 url 탐지가 가능하다.

컨테이너 인사이트

컨테이너화 된 어플리에이션 및 마이크로 서비스의 지표 및 로그를 수집하고 요약 가능 ECS , EKS, EC2 환경에서도 사용 가능

Fargate 리소스에서도 데이터 수집 가능

CPU, 메모리 , 디스크, 네트워크 같은 많은 리소스에 대한 지표를 자동으로 수집

컨테이너 재시작 오류 같은 진단 정보를 재공하여 오류를 빨리 해결할 수 있도록 도와줌

임베디드 지표 형식을 사용하여 데이터를 성능 로그 이벤트로 수집

성능 로그 이벤트는 카니널리티가 높은 데이터를 저장할 수 있게 하는 구조화 된 json을 스키마를 사용하는 항목

firelens는 fluent bit 및 fl vented와 함께 동작 

람다 인사이트

서버리스 어플리케이션에 대한 모니터링 및 문제 해결 솔루션

Cpu, 시간, 메모리, 디스크 성능 이벤트를 수집

사용자 지정 지표를 자동으로 생성

콜트 스타트 및 람다 작업자 종료와 같은진단 정보를수집 집계 요약 , 람다 관련문제를 격리하고 신속하게 해결할 수 있도록 도와준다.

시스템 수준 지표를 수집, 람다 함수가 호출될 때마다 단일 성능 로그 이벤트를 내보냄

클라우드 워치는 로그 이벤트에서 지표를 추출하여서 람다 인사이츠 네임스페이스에 함수 이름별로 저장

람다 인사이트에서는 다중 함수 개요를 보거나 단일 함수에 집중할 수 있다.

HTTP 란

HTTP는 서로 다른 클라이언트와 서버 간 통신을 위한 기초적인 통신 규칙 세트 또는 프로토콜이다. 

사용자가 웹 서비스에 접속하면 클라이언트는 80번 포트를 통해 웹 서버에 HTTP 요청을 보내고 응답을 받는다. 이렇게 함으로써 데이터를 일반 텍스트로 교환할 수 있다.

예를 들어, 사용자가 HTTP의 요청 종류인 GET을 보내면 서버는 그에 맞는 응답 및 상태 코드를 보낸다. 상태 코드 예시는 다음과 같다.

200 - OK(정상)
400 - Bad request(잘못된 요청)
404 - Resource not found(리소스를 찾을 수 없음)

HTTP는 TCP/IP 위에서 작동하는 무상태(stateless) 프로토콜이며 다음과 같은 구조를 가진다.

하지만 HTTP는 평문 데이터를 전송하기에 제 3자가 그 데이터를 조회할 수 있다는 보안 이슈가 있다.

HTTP REQUEST 방식 종류

HTTP 버전 별 차이

HTTP/1.0

기본적으로 연결의 수명이 짧으며 HTTP 요청당 TCP hand-shake가 발생해서 각각 연결을 처리한다.

이로 인해 서버의 오버헤드가 발생하고 *RTT가 늘어나는 문제가 있었다.

RTT(Round Trip Time) : 어떤 메세지가 두 장치 사이를 왕복하는 데 걸린 시간

HTTP/1.1

1.0 버전의 단점을 보완한 프로토콜이다. 크게 3가지의 개선점이 있다.

1. keep alive default

요청할 때마다 TCP 연결을 하는 것이 아닌 keep alive 옵션을 기본 옵션을 함으로써 계속해서 데이터를 받을 수 있다.

2. 호스트 헤더

1.1 버전부터 서버는 여러 대의 호스트를 가질 수 있으며 항상 호스트를 헤더에 포함에서 요청을 보내야한다.

3. Persistent Connection (대역폭 최적화)

지정한 time out 시간 내에 기존 connection을 재사용할 수 있다. 

기존에는 파일을 다운로드 받다가 끊기면 처음부터 받아야했지만, 1.1 버전부터 이어서 다시 다운로드 받을 수 있다.

이외에도 요청을 최소화하기 위한 여러 기술들을 도입했다.

1. 이미지 스프라이트

하나의 이미지만 다운받고 여러 개의 이미지를 다운받은 듯한 효과를 낸다.

2. 코드 압축

3. Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩해서 이미지 서버에 대한 HTTP 요청을 줄인다.

하지만 파일 크기가 더 커진다는 단점이 있다.

HTTP/1.1의 문제점 : HOL

그러나 HTTP/1.1 은 HOL(Head Of Line Blocking)이라는 고질적인 문제가 있었다.

HTTP/1.1부터는 여러 요청을 보내고 순서대로 응답을 받는 파이프라이닝이 가능해졌는데 이로 인해 치명적인 문제가 생겼다.

예를 들어 파이프라인으로 인해 1번 요청에 문제가 생기면 그 뒤에 요청이 줄줄이 지연되는 것이다.

RFC 문서 원칙에 따라 요청이 온 순서대로 처리해야 되기 때문에 다음과 같은 문제가 생겼다.

HTTP/2.0

바이너리 포맷 계층

더 작은 프레임으로 메세지를 전송하기 위해 어플리케이션과 통신 계층 사이에 바이너리 포맷 계층을 추가하였다. 

멀티 플렉싱

단일 TCP 연결에서 스트림을 통해 여러 HTTP 요청과 응답을 비동기적으로 받을 수 있다.

기존에는 다중 TCP 연결을 통해서만 병렬 요청이 가능했지만 HTTP/2.0 부터는 리소스를 작은 프레임으로 나누고 스트림으로 프레임을 병렬적으로 전달한다. 이를 통해 HTTP/1.1의 문제인 HOL을 해결할 수 있다.

또한 각각의 프레임은 스트림 id가 있기 때문에 응답 순서와 상관없이 데이터를 조립할 수 있다.

서버 푸시

클라이언트의 별도 요청이 없더라도 서버가 필요할 것 같은 데이터를 미리 응답에 같이 보낼 수 있다.

헤더 압축

무거운 헤더를 최소화하기 위해 중복된 헤더는 한번만 보내고 중복되지 않은 값은 *허프만 인코딩을 통해 압축시킨다.

허프만 인코딩: 문자열을 문자 단위로 쪼개서 빈도가 높은 정보는 적은 비트수를 사용하고, 빈도가 낮은 정보는 비트수를 많이 사용한다.

우선 순위

서버에서 원하는 순서대로 우선순위를 정해서 리소스를 전달할 수 있다.

HTTP/3.0

TCP 연결로 인한 오버헤드 및 RTT 시간 증가의 문제점을 해결한 버전이다.

이 버전부터 UDP 프로토콜 기반의 QUIC(Quick UDP Internet Connections)로 동작하며 이전 버전들의 장점, 특징들은 대부분 가지고 있다.

또한 QUIC는 TLS로 암호화 통신을 구축할 때 hand shake를 통해 서버와의 연결까지 진행함으로써 1-RTT만에 연결을 수립할 수 있다.

기존 UDP는 데이터의 무결성을 보장하지 못하는 프로토콜이었지만, QUIC는 에러를 검출하고 수정할 수 있는 순방향 오류 제어 메커니즘을 가지고 있다.

HTTPS와의 차이점

HTTP의 보안적인 한계를 SSL/TLS를 사용함으로써 해결한 것이 HTTPS이다.

SSL은 서버와 클라이언트 사이에 암호화 된 연결을 만들어주고 데이터들이 도난되는 것을 방지한다.

SSL 인증서는 클라이언트와 서버 간 주고받는 데이터들을 암호화한다. 그렇기 때문에 데이터가 탈취된다 하더라도 암호화 된 상태이기 때문에 제 3자는 알 수 없다.

또한 SSL 외에도 TLS 프로토콜을 통해서도 데이터 무결성을 제공함으로써 보안을 강화한다.

HTTPS는 보안 상의 이점도 있지만 구글이 안전하다고 신뢰하는 사이트라는 반증이기 때문에 검색엔진 최적화(SEO)측면에서도 많은 이점을 얻을 수 있다.

HTTPS의 동작 방식

HTTPS의 가장 큰 특징은 암호화를 한다는 점인데 암호화 방식은 크게 두가지로 분류된다.

암호화를 통해 의도된 송수신자를 제외하고는 데이터 유출을 방지하고 데이터의 무결성을 보장한다.

대칭키 암호화

클라이언트와 서버가 동일한 키를 하나만 사용해서 암호화한다.

키가 노출될 위험이 있지만 연산 속도가 빠르다는 장점이 있다.

ex)

Plaintext + key = ciphertext: hello + 2jd8932kd8 = X5xJCSycg14=

Ciphertext + key = plaintext: X5xJCSycg14= + 2jd8932kd8 = hello

-> 만약 데이터를 전송하는 과정에서 key를 탈취당하면 제 3자가 데이터를 볼 수 있다.

비대칭키 암호화

두 개의 다른 키로 데이터를 암호화하거나 복호화하고 공개키는 누구나 사용할 수 있다.

예를 들어 공개키로 암호화된 데이터는 개인키로만 복호화가 가능하다.

암호화를 개인키로 할것인지 공개키로 할 것인지에 따라 얻는 효과가 달라진다.

공개키 암호화: 개인키로만 복호화할 수 있으므로 해당 데이터는 자신만 확인 가능하다.

대칭키 암호화 방식은 데이터 전송 과정에서 키가 탈취될 위험이 있었지만 공개키 암호화 방식은 공개키가 탈취되도 상관이 없다.

수신측에서는 공개키로 암호화 한 다음에 다시 개인키로 복호화해서 데이터를 확인할 수 있다.

제3자는 개인키를 가지고 있지 않기 때문에 공개키로 암호화된 데이터를 탈취하더라도 데이터를 확인할 수 없다.

개인키 암호화: 모두에게 공개된 공개키로 복호화하므로 인증된 정보임을 신뢰할 수 있다.

A는 원본 데이터와 개인키로 암호화된 데이터를 전송한다. 그러면 B에서는 공개키를 통해 암호화된 데이터를 복호화하고 해당 데이터가 원본 데이터와 일치하면 신뢰할 수 있는 정보임을 인증할 수 있다.

하지만 공개키로 복호화를 하였을 때 원본 데이터와 다르다면 해당 데이터는 A가 아닌 제3자가 암호화한 데이터이므로 신뢰할 수 없다.

TLS Hand Shaking

SSL은 SSL 1.0 부터 시작해서 명칭이 바뀌어 TLS 1.3 버전에 이르렀다.

TLS는 전송 계층에서 제 3자가 메세지를 도청하거나 변조하지 못하게 보안을 제공하는 프로토콜이다.

이 과정에서 비대칭키 암호화와 대칭키 암호화를 모두 사용하여서 빠른 연산 속도와 안정성을 제공한다.

먼저 처음 연결이 진행될때는 안전한 연결을 위해 속도가 다소 느린 비대칭키 암호화를 사용하고, 이후에는 빠른 통신을 위해서 대칭키를 사용한다.

Client : Client Hello

패킷에 TLS Version, Client가 지원하는 암호화 방식(사이퍼슈트), Client Random Data(클라이언트에서 생성한 난수로 대칭키를 만들 때 사용), 임시 *DH변수, SNI(서버명) 를 담아서 보낸다.

DH 매개변수 : DH는 Die-Hellman을 의미하며 Die-Hellman 알고리즘은 서로 공개값 공유,비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘이다. 모든 TLS 통신이 DH 매개변수를 사용하지는 않음

Server Hello, EncryptedExtensions, Certificate, CertificateVerify

서버는 클라이언트로부터 받은 옵션을 확인하고 공개키가 포함된 인증서와, 서버랜덤값, DH 매개변수를 브라우저에 보낸다.

Client : Client Key Exchange

클라이언트가 서버로부터 받은 DH매개변수(혹은 공개키)를 이용하여 세션키를 생성한다.

이렇게 생성된 세션키를 다시 공개키로 암호화해서 서버에 보내면, 서버는 개인키로 복호화를 할 수 있다.

Server & Client : Finished

클라이언트와 서버의 세션키를 기반으로한 대칭 암호화된 통신이 시작된다.

만약 세션키가 생성된 이후 다시 그 사이트에 방문한다면, 미리 만들어놓은 세션키로 통신하기 때문에 인증에 드는 비용은 없다.

TCP - 전송 제어 프로토콜 

TCP 프로토콜은 순서를 보장하고 연결지향적이라는 특징이 있으며 가상 회선 패킷 교환 방식을 사용한다.

IP의 단점이었던 패킷 손실이나 순서 미보장 같은 문제들을 패킷을 제어하여 해결해 준다.

가상 회선 패킷 교환 방식

가상회선 패킷 교환 방식은 각 패킷에 가상회선 식별자가 포함되고 패킷들이 순서대로 도착하는 방식이다.

모든 패킷을 전송하면 가상 회선이 해제된다.

TCP 프로토콜은 연결을 시작할 때 3 way 핸드셰이크 방식을 사용하며 연결을 종료할 때 4way 핸드 셰이크 방식을 사용한다.

3way 핸드셰이크

- SYN : 클라이언트는 서버의 *ISN과 SYN을 보낸다. 

*ISN : TCP 연결의 첫 번째 패킷에 할당된 임의의 시퀀스 번호이다. 지연 전송된 패킷의 포트 번호로 인식하는 상황을 방지하기 위해 임의의 난수를 사용한다. 또한 임의의 난수를 사용함으로써 예측이 힘들게 만들어 보안을 강화시킨다.

- SYN + ACK : 서버는 클라이언트의 SYN을 받고 응답값으로 서버의 ISN과 승인번호로 ISN + 1을 보낸다.

- ACK : 클라이언트는 서버의 승인 번호를 담아서 ACK를 보낸다.

이 과정이 구축되고 난 뒤에 데이터 전송을 시작하기 때문에, TCP는 신뢰성이 있다고 말할 수 있다.

하지만 모든 통신에서 이 과정을 진행해야 하기 때문에 실시간 처리 같은 속도가 중요시 되는 통신에는 적합하지 않다.

4way 핸드셰이크

- FIN_WAIT_1 : 클라이언트가 연결을 닫으려고 할 때 FIN으로 설정된 세그먼트를 보내면 서버의 응답을 기다리면서 FIN_WAIT_1의 상태가 된다.

- CLOSE_WAIT : 서버는 클라이언트로 ACK라는 승인 세그먼트를 보내고 서버는 CLOSE , 클라이언트는 FIN_WAIT2 상태에 들어간다.

- LAST_ACK : 서버는 ACK를 보내고 일정 시간 이후에 FIN이라는 세그먼트를 보낸다.

- *TIME_WAIT : 일정 시간을 기다린 뒤에 서버로 ACK를 보내서 서버는 CLOSED 상태가 된다. 이후 클라이언트의 연결이 닫히면 클라이언트와 서버의 모든 자원의 연결이 해제된다.

TIME_WAIT : 소켓이 바로 소멸되지 않고 일정 시간 동안 유지되는 상태이며, 지연 패킷이나 연결 오류 등의 문제를 해결하기 위해 존재한다.

2way 핸드셰이크가 없는 이유 : 전송 측 입장에서 자기의 신호가 제대로 전달되었는 지 확인할 수 없다. 이는 TCP의 근본인 양뱡향 연결이 깨져버리게 되고 곧 신뢰성을 보장할 수 없게된다.

TCP 전송 제어

흐름제어

송신 측은 수신 측의 데이터 처리 속도를 파악하고 데이터를 어느 정도로 보내줘야 할지를 제어할 수 있다.

ex) 슬라이딩 윈도우 방식을 사용하여서 동적으로 데이터량을 조절

오류제어

통신 도중에 데이터가 유실되었을 경우에 대해서 대처할 수 있다.

ex) go back n - 데이터가 유실된 시점부터 다시 데이터를 보낸다. 

selective repeat - 유실된 데이터만 선택적으로 보낸다. 

혼잡제어

네트워크 혼잡을 감지하여서 상황에 맞게 송신 측의 데이터 전송량을 조절한다.

ex)

AIMD

- 송신 측이 transmission rate(window size)를 패킷 손실이 일어날 때까지 증가

Slow Start

- Slow Start는 송신 측이 window size를 1부터 패킷 손실이 일어날 때까지 지수승(exponentially)으로 증가

TCP 헤더

TCP 프로토콜은 여러 기능들을 제공해주기 때문에 시퀀스 번호나 ACK 번호같은 다양한 정보들을 헤더에 담고 있다.

TCP의 특징 정리

1. 연결 지향(가상회선 패킷 교환) 방식을 사용한다.

2. 3way , 4way 핸드 셰이크를 통해 연결을 수립하고 해제한다.

3. 신뢰성을 보장하기 위해 여러 전송 제어 기능들을 제공한다.

4. 패킷에 대한 응답을 받아야하기 때문에 상대적으로 속도가 느리다.

UDP - 사용자 데이터그램 프로토콜

데이터그램 단위로 데이터를 전송하는 프로토콜이다. TCP의 고질적인 문제인 속도로 인해서 빠른 처리가 요구되는 현대에 필요성이 대두되었으며 HTTP/3.0에서 표준으로 채택되었다. 

하지만 빠른 속도 대신 전송 제어나 핸드 셰이크(비연결성) 같은 기능들은 제공하지 않는다.

데이터그램 패킷 교환 방식

데이터그램을 사용하여서 데이터의 순서를 신경쓰지 않고 목적지로 라우팅 하는 역할만 수행한다.

이 과정에서 핸드 셰이크나 전송 제어같은 기능도 수행하지 않기 때문에 속도는 더 빨라진 대신 데이터의 무결성은 떨어진다.

UDP 헤더

UDP 프로토콜은 상대적으로 단순하기 때문에 헤더에서도 많은 정보를 담고 있진않다.

checksum 필드를 통해 최소한의 오류 검출은 수행한다.

UDP의 특징 정리

1. 비연결형 프로토콜이며, 데이터그램 패킷 교환 방식을 사용한다.

2. 연결 과정에서 별도의 절차를 거치지 않는다. -> 수신 여부를 확인할 수 없다.

3. 신뢰성이 낮은 대신 속도가 빠르다.

4. 속도가 중요시되는 실시간 서비스에 적합하다.

메모리 계층 구조 

메모리는 다음과 같이 계층 구조로 구성되어있다. 일반적으로 상위 계층으로 갈수록 속도는 빨라지는 대신 가격은 비싸진다.

속도가 빠른 캐시나 레지스터에 모든 프로세스를 저장해놓으면 좋겠지만 그러지 못하는 이유가 경제성 때문이다.

따라서 느린 저장장치에 데이터를 저장해놓고 빠른 장치는 필요할 때마다 데이터를 불러와서 처리하는데, 메모리와 CPU 사이의 속도 차이가 너무 크기 때문에 중간에 레지스터 계층과 캐시 계층을 두어서 관리한다.

캐시

위에서 말했던 것처럼 캐시는 필요한 데이터를 보관하는 임시 저장소이자 병목 현상을 줄이기 위한 메모리이다.

캐시를 통해 CPU의 연산 속도와 메모리 접근 속도의 차이를 완화할 수 있다.

계층적 캐시 메모리

메모리 구조가 그랬던 것 처럼 캐시 메모리 또한 캐시를 계층적으로 관리한다.

일반적으로 L1, L2 캐시는 CPU 코어 내부에 위치하며 L3는 CPU가 아닌 메인보드에 위치한다.

참조 지역성의 원리

필요한 데이터가 캐시에 있는 경우를 캐시 히트라고 하고 없는 경우를 캐시 미스라고 한다. 당연히 캐시 히트가 많이 일어나는 것이 좋은 건데, 적중률을 높이기 위해 지역성의 원리가 사용된다.

*캐시 히트는 CPU 내부 버스를 사용하고 캐시 미스는 시스템 버스를 사용한다. (당연히 CPU 내부 버스가 더 빠르다!)

지역성은 두가지로 구분된다. 예시 코드와 함께 보면 이해가 쉽다.

List<Integer> list = new ArrayList<>();

for(int i=0;i<10;i++) {
	list.add(i);
}

시간 지역성

- CPU는 최근에 사용했던 메모리 공간에 다시 접근하는 경향이 있다.

- 예시 코드에서 변수 i에 대해서 계속해서 접근이 이루어지고 있다.

참조 지역성

- CPU는 최근에 사용했던 메모리 공간 근처를 접근하는 경향이 있다.

- 예시 코드에서 list 공간에 계속해서 접근하고 있다.

캐시 매핑

캐시 메모리는 매우 작고 주 메모리를 크기 때문에 캐시를 어떻게 매핑하느냐가 매우 중요하다. 또한 CPU에서 캐시를 탐색할 때 효율적으로 탐색을 할 수 있어야한다.

직접 매핑

- 메모리가 1~100이 있고 캐시가 1~10이 있다면 1:1~10 , 2: 11:~20 .. 같은 방식으로 저장한다.

- 구현이 간단하고 처리가 빠르지만 충돌(스와핑)이 잦다.

연관 매핑

- 순서와 블록 상관없이 자유롭게 매핑을 할 수 있다.

- 충돌은 덜 일어나지만 모든 블록을 탐색해야하므로 속도가 상대적으로 느리다.

집합 연관 매핑

- 직접 매핑과 연관 매핑의 절충안이다.

- 정해진 장소(직접 매핑) 내에 어느 장소에나(연관 매핑) 매핑이 가능하다.

- 직접 매핑에 비해 저장이 빠르고 연관 매핑보다 검색이 빠르다. 

캐시와 레지스터의 차이

레지스터는 CPU 내에서 연산을 처리하기 위해 데이터를 저장하는 메모리이며, 캐시는 메인 메모리와 CPU 간의 속도 차이를 극복하기 위한 메모리이다.

레지스터는 CPU 내부에 위치해 있으며 캐시는 CPU와는 별도로 존재한다. 

네트워크란

통신 분야에서 단말기 등을 접속하기 위해 사용되는 단말기기, 선로 및 교 환기 등으로 구성되는 전송매체이다.

프로토콜

통일을 위한 상호 간의 규약(약속)이다.

프로토콜의 구성 요소

1. 구문(syntax)

- 데이터를 어떻게 구성할지 , 코딩 방법 , 신호 레벨 등에 대한 정보

- 데이터 포맷(형식), 부호화, 신호 레벨 등

2. 의미(semantic)

- 데이터나 예외에 대해 어떻게 처리할 것인지에 대한 정보

- 특정 패턴을 어떻게 해석하고, 어떤 동작을 할 것인가 결정

3. 타이밍(timing) 

- 통신이 이루어질 때 데이터를 주고 받을 속도에 대한 조절과 여러 데이터가 동시에 통신을 해야 할 경우 순서 관리를 위한 기법

- 속도 일치 및 순서 제어

프로토콜의 역할

1. 에러 제어 (Error Control)
     - 전송 중 에러 검출 및 에러 정정
2. 캡슐화 (Encapsulation)
     - 통신계층 상의 각 계층이 자신 만의 특정제어정보(주로 Header)를 추가하는 것
3. 연결 제어 (Connection Control) 또는 세션 관리
     - 연결지향적 통신에서 연결설정,데이터전달,연결종료 절차의 제어
4. 순서 제어 (Sequence Control)
     - 순서 역전, 중복 패킷 발생 등의 방지
5. 흐름 제어 (Flow Control)
     - 보낼 데이터량/전송률의 제한
6. 혼잡 제어 (Congestion Control)
     - 포화/대기 패킷 수의 제한을 위한 제어 기법
7. 동기화 (Synchronization)
     - 송수신 양측 간에 시간 관계(주로,위상)의 일치
8.주소 지정 (Addressing)
     - 호스트/디바이스/프로세스 등을 유일하게 식별할 수 있는 방법을 제공
9. 단편화 및 재조립 (Segmentation and Reassembly, Fragmentation and Reassembly)
     - 데이터 패킷을 전송에 적당한 크기로 분해,조립
10. 데이터의 형식화 (Data Formatting) 등

패킷

패킷 스위칭 방식에서 네트워크를 통해 전송되는 데이터 블록이다.

패킷을 사용하는 이유

데이터를 한번에 보내게 된다면 통신 대역폭을 많이 차지하기 때문에 다른 데이터의 전송이 지연되며 이는 곧 통신의 문제로 이어질 수 있다.

패킷 구조

네트워크 패킷은 헤더(Header), 페이로드(Payload), 트레일러(Trailer) 세 부분으로 구성

1. 헤더

- 패킷 길이, 프로토콜, 보낸/받는 사람의 IP 주소 등이 포함

- 패킷의 주소(송수신 주소) 등 주요 제어 정보들이 포함

2. 페이로드

- 패킷의 본문 (내용 , 데이터)

3. 트레일러 (footer)

- 패킷의 끝에 도달했음을 수신 컴퓨터에 알리는 비트 포함

- 패킷 에러 검출 등에 사용 
- 패킷 꼬리가 없는 경우도 많음

CBN(Curcuit Based Network) vs PBN(Packet Based Network)

CBN

1. 전화망에 사용

2. 연결 지향 (connection-oriented)

3. 자원 점유 -> QoS 보장

PBN

1. 인터넷

2. connection less service

3. 자원 공유 방식 -> QoS 보장x , Best effort

OSI 7 Layer

7계층 - 응용 계층

통신을 위한 어플리케이션 - 카카오톡

GUI로 구성 된 경우가 많다.

주요 프로토콜 - TELNET, FTP, SMTP, HTTP 등

6계층 - 표현 계층

데이터를 어떻게 표현할 지에 대해 결정

Codec(coding+decoding) 관련 인코딩/디코딩, 압축/해제, 암호화/복호화 등의 역할을 수행한다.

ex) avi, mp4, mp3

5계층 - 세션 계층

사용자의 구분. 누구와 통신 할 것인가? 에 대해 결정

Session ID : 누구와 통신 할 것인지를 구분할 수 있도록 알려주는 구분자 (ID)

TCP/IP 통신 연결을 수립/ 유지/중단

4계층 - 전송 계층

어떤 *port로 전송할 것인가? 에 대해 결정

port : process를 특정하기 위한 주소

포트의 종류

0~1023: well-known port. 표준화되어 있는 포트

– 20 FTP, 23 Telnet, 53 DNS, 80 HTTP, 433 HTTPS

1024~49151: registered port. 상업적인 어플리케이션을 개발하는 회사들이 등록하 여 사용하는 포트

49152~65535: dynamic port. 사용자(개발자) 자유롭게 즉흥적으로 할당하여 사용할 수 있는 포트

UDP vs TCP

UDP: TCP 대비 프로토콜이 간결함. 가볍고 빠름. QoS 보장 x

– real-time service: 실시간 비디오

TCP: UDP 대비 프로토콜이 복잡함. 무겁고 느림. UDP 대비 QoS 일부분 보장

– retransmission, timeout 특성을 가지고 흐름제어, 오류제어

– non-real-time service: email 서비스, 문자 서비스

3계층 - 네트워크 계층

End to End 통신을 담당 (source-to-destination)

라우터를 통해 IP를 사용하여 통신한다. (라우팅)

- DNS를 이용하여 도메인 이름으로 IP를 알 수 있다.

주요 프로토콜 - IP, ARP, ICMP, IGMP, RIP, RIP v2, OSPF, IGRP, EIGRP, BGP 등

2계층 - 데이터 링크 계층

스위치를 통해 *MAC 주소를 이용하여 목적지를 찾아간다 (hop by hop , node to node)

MAC : 고유한 하드웨어 주소

주요 프로토콜 : HDLC, X.25, Ethernet, TokenRing, DFFI, FrameRelay 등

1계층 - 물리 계층

디지털 데이터를 아날로그적인 전기적 신호로 변환

데이터를 비트형태로 표현

Topology: 망의 구성

ex) Star, mesh, bus…

TCP/IP Layer

OSI 참조 모델을 기반으로 상업적이고 실무적으로 이용될 수 있도록 단순화된 현실화의 과정에서 채택된 모형이다. 

인터넷이 발전되는 과정에서 대부분 TCP/IP 계층 구조를 사용했기 때문에 지금도 대부분의 통신이 사용하고 있는 프로토콜 구조이다.

TCP/IP 계층은 OSI 7 계층 구조와 달리 4개의 계층을 가지고 있다.

어플리케이션 계층 , 전송 계층 , 인터넷 계층 , 네트워크 인터페이스 계층으로 구성되어 있으며 각각의 계층은 서로 영향을 받지 않도록 설계되었다.

1. 어플리케이션(application) 계층

FTP , HTTP 같은 응용 프로그램이 사용되는 프로토콜 계층이며 실질적으로 사람들에게 서비스를 제공해준다. 

OSI 7 계층의 어플리케이션 계층과 흡사

2. 전송 계층(transport) 계층

송신자와 수신자를 연결해주는 통신 서비스를 제공한다. 

전송 계층에서 사용하는 기술로는 TCP와 UDP가 있으며 어플리케이션 계층과 인터넷 계층 사이에서 중계 역할을 한다.

OSI 7 계층의 전송 계층과 흡사

3. 인터넷 계층

네트워크 패킷을 IP 주소로 지정된 목적지로 전송한다. 

*ARP , IP 같은 기술을 사용하며 데이터의 수신 상태를 보장하지 않는 비연결형 통신을 제공한다.

OSI 7 계층의 네트워크 계층과 흡사

ARP : IP주소에 해당하는 MAC 주소를 매칭시켜주는 프로토콜 , 반대의 개념으로 RARP도 있다.

4. 네트워크 인터페이스 계층

전선 , 광섬유 , 무선 등으로 실질적으로 데이터를 전달한다. -> 장치 간의 신호를 주고 받는 규칙을 정한다.

물리 계층과 데이터링크 계층으로 나누어 보기도 한다. 

물리계층은 무선 LAN이나 유선 LAN을 통해 0과 1로 이루어진 데이터를 전송하고 데이터 링크 계층은 이더넷 프레임을 통해 MAC 주소를 사용하여 전송한다.

계층 간 데이터 송수신 과정

기본적으로 요청 값들이 캡슐화되어서 전달되고 요청 받는 서버가 다시 비캡슐화 과정을 거치면서 데이터가 전송된다.

Encapsulation과 Decapsulation

Encapsulation - 상위 계층의 헤더와 데이터를 하위 계층의 데이터 부분에 포함시키고 해당 계층의 헤더를 삽입한다.

Decapsulation - 하위 계층에서 상위 계층으로 가면서 각 계층의 헤더 부분을 제거한다.

OSI 7 Layer 또는 TCP/IP Layer에서 계층화하는 이유

네트워크를 이루고 있는 구성 요소들을 계층 별로 나누고 표준화함으로써 포트 , 프로토콜의 호환 문제를 해결할 수 있다.

(각 계층끼리만 통신하기 때문)

문제가 발생했을 때 계층들간의 영향을 주지 않기 때문에 문제 생긴 계층의 범위 내에서 원인을 추적해나갈 수 있다. 

또한 각 계층의 장비나 기술의 변경에 대해 유연하다는 장점이 있다.

IP(Internet Protocol)란?

인터넷에서 네트워크의 두 호스트(host) 간에 통신할 때 호스트 주소를 지정하고 전송 계층의(transport layer)의 정보를 패킷으로 분할/조립하며, 패킷을 IP 주소에 따라 목적지에 전송하는 통신 규약이다.

송신측에서는 패킷에 목적지 주소를 표기하고 각각의 라우터들은 해당 목적지를 확인하고 라우팅 테이블을 참조하여 다음 라우터로 라우팅시킨다. 최종적으로는 목적지까지 패킷을 전송한다.

이렇게 패킷이 여러 개의 라우터를 건너가는 것을 hop-by-hop 통신이라고 한다.

IP 주소란?

IP주소란 네트워크에 연결되어 있는 디바이스의 네트워크상 주소(식별자)이다.

IPV4 vs IPV6

IPv4 체계 주소의 고갈과 확장성 면에서의 한계로 인해 나온 새로운 주소 체계이다. IPv4는 클래스 기반의 할당 방식을 사용했는데 이 방식은 사용하는 주소보다 버리는 주소가 많은단점이 있었고 확장성에 한계가 있었다.

따라서 더 많은 주소를 가질 수 있고 차세대 멀티 미디어 환경에도 용이한 IPv6가 나오게 되었다.

IPv4는 32비트를 8비트 단위로 점을 찍어서 표현한다. ex) 123.45.67.89

IPv6는 64비트를 16비트 단위로 점을 찍어 표기한다. ex) 2001:db8:ff00:42:8329

아직까지는 여전히 IPv4가 가장 많이 쓰이는 주소 체계이다.

IPv64와 IPv6의 차이점 비교

IPv4의 주소 부족현상을 해결하기 위한 방법

DHCP

- 주소를 수동으로 할당할 필요 없이 인터넷에 접속할 때마다 IP주소를 자동으로 할당 받는다. (plug & play)

NAT

- 패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP 정보를 수정하여 다른 주소로 매핑한다.

IPv4 체계로는 많은 주소들을 감당하지 못했었는데 이를 해결하기 위해 공인 IP와 사설 IP로 나누어서 주소를 처리하게 되었다.

NAT를 통해 하나의 공인 IP로 사용자들은 각각의 다른 IP를 가진것처럼 인터넷을 이용할 수 있다. (공유기에서 주로 사용된다.)