목록Network & Security (16)
우노
HTTP(Hyper Text Transfer Protocol)란? HyperText 문서(ex. html)를 주고받는 프로토콜입니다. ex) 클라이언트가 웹 브라우저에 URL을 입력하면, 웹 서버에 HyperText 문서를 요청하고 응답받는 과정이 진행됩니다. HTTP 요청(Request) 예제 GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3 Accept: text/html,application/xhtml+xml,application/xml;q=..
선요약 Sync / Async 는 호출된 함수의 종료를 호출한 함수가 처리하느냐, 호출된 함수가 처리하느냐의 차이입니다. Sync A 함수가 B 함수를 호출 할 때, B 함수의 결과를 A 함수가 처리하는 것입니다. Sync 작업들이 연속적으로 실행될 땐, 작업의 순서가 유지됩니다. Async A 함수가 B 함수를 호출 할 때, B 함수의 결과를 B 함수가 처리하는 것입니다. Async 작업들이 연속적으로 실행될 땐, 작업의 순서가 유지되지 않을 수 있습니다. Blocking / Non-blocking 은 호출된 함수가 호출한 함수에게 제어권을 바로 주느냐 안주느냐의 차이입니다. Blocking A 함수가 B 함수를 호출 할 때, B 함수가 자신의 작업이 종료되기 전까지 A 함수에게 제어권을 돌려주지 않는..
Username과 Password를 사용해 Client에 접근하고 있다면 아래 curl post 명령어를 통해 토큰을 발급 받을 수 있습니다. curl -X POST '/realms//protocol/openid-connect/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=password' \ --data-urlencode 'client_id=' \ --data-urlencode 'client_secret=' \ --data-urlencode 'username=' \ --data-urlenc..
부하 분산 알고리즘 로드 밸런서가 리얼 서버로 부하를 분산할 때, 로드 밸런서에서는 사전에 설정한 분산 알고리즘을 통해 부하 분산이 이루어집니다. 기본적인 부하 분산 알고리즘은 5가지 종류가 있습니다. 라운드 로빈(Round Robin) 현재 구성된 장비에 부하를 순차적으로 분산함 총 누적 세션 수는 동일하지만 활성화 된(처리 중인) 세션 수는 달라질 수 있음 최소 접속 방식(Least Connection) 현재 구성된 장비 중 가장 활성화 된(처리 중인) 세션 수가 적은 장비로 부하를 분산함 가중치 기반 라운드 로빈(Weighted Round Robin) 라운드 로빈 방식과 동일하지만 각 장비에 가중치를 두어 가중치가 높은 장비에 부하를 더 많이 분산함 처리 용량이 다른 서버에 부하를 분산하기 위한 분..
들어가기 앞서, CIDR은 네트워크를 설계하면서 가장 많이 접하게 되는 개념입니다. CIDR의 full name은 Classless Inter-Domain Routing으로, 클래스 없는 도메인간 라우팅 기법이라는 뜻입니다. 클래스가 없다는 뜻은, 네트워크 구분을 Class로 하지 않는다는 것입니다. Class는 사이더가 나오기 전 사용했던 네트워크 구분 체계입니다. 사이더가 나오면서 Class 체계보다 더 유연하게 IP 주소를 여러 네트워크 영역으로 나눌 수 있게 되었습니다. 해당 포스트에선, CIDR 계산 방법에 대해서 다뤄보겠습니다. IP 표현 방식 CIDR을 이해하기 전에, IP 표현 방식을 알아야합니다. IP는 옥텟이라는 단위로 이루어져 있습니다. 하나의 옥텟은 8비트로 이루어져 있으며, 일반적..
SKT 기본 DNS 서버 : 219.250.36.130 보조 DNS 서버 : 210.220.163.82 KT 기본 DNS 서버 : 168.126.63.1 보조 DNS 서버 : 168.126.63.2 LG 기본 DNS 서버 : 164.124.101.2 보조 DNS 서버 : 203.248.252.2 구글 (Google Public) 기본 DNS 서버 : 8.8.8.8 보조 DNS 서버 : 8.8.4.4 참고 https://overcode.tistory.com/entry/통신사별-DNS-서버-아이피-주소-SKT-KT-LG-구글
인증(Authentication)과 인가(Authorization)의 차이 인증 단계에서는, 사용자의 신원을 확인합니다. 인가 단계에서는, 신원이 확인된 사용자에게 리소스에 액세스할 수 있는 권한을 부여합니다. OpenID Connect(OIDC)와 OAuth 2.0의 차이 OpenID Connect(OIDC) Oauth 2.0을 포함하여 인증과 인가를 모두 포괄하는 확장 인증 프로토콜이며, 주로 인증(본인 증명)에 초점을 맞추고 있습니다. 한 사이트에서 로그인하면 다른 사이트에서도 로그인 되는 SSO(Single Sign-On) 기능 구현을 위한 대표적인 수단으로 사용됩니다. OAuth 2.0 권한 부여 프레임워크로, 인가(데이터에 대한 액세스 권한 부여)에 초점을 맞추고 있습니다. OAuth 2.0 ..
들어가기 앞서, 모든 HTTP 응답 코드는 5개의 클래스로 구분됩니다. 상태 코드의 첫 번째 숫자는 응답 클래스를 의미하며, 다음과 같습니다. 1xx (정보): 요청을 받았으며 프로세스를 계속한다. 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다. 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다. 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다. 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다. 해당 포스트에선, 개인적으로 주로 확인하는 HTTP 상태 코드에 대해서 정리합니다. 4xx (요청 오류) 403 (Forbidden, 금지됨) 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을..
들어가기 앞서, 3-Way Handshaking 과정은, TCP 프로토콜 통신을 ‘연결’하기 위한 과정이고 4-Way Handshaking 과정은, TCP 프로토콜 통신을 ‘종료’하기 위한 과정입니다. 3-Way Handshaking 패킷을 전송하기 전, TCP는 연결지향형 프로토콜이기 때문에, 송신측과 수신측이 서로 연결되는 작업이 필요합니다. 이러한 작업을 3 Way Handshaking 이라고 부릅니다. 3 Way Handshaking 을 수행하기 위해서는, TCP 헤더에 표시한 플래그들이 사용되며, 이러한 플래그들을 컨트롤 비트라고 부릅니다. 3 Way Handshaking 은 SYN(동기화) 과 ACK(승인) 로 진행됩니다. 먼저, 클라이언트는 서버에게, 접속을 요청하는 SYN 패킷을 보냅니다...
들어가기 앞서, 만약, www.google.com 을 웹 브라우저에 입력하면 무슨 일이 일어날까요? 구글 웹서버에 80번 포트로 HTTP Request 를 보낸다는 의미와 동일합니다. 해당 포스팅에선, 웹 요청 및 응답의 흐름을 간단하게 요약하고, 자세한 내용까지 다뤄보겠습니다. 흐름 간단 요약 www.google.com 을 브라우저 주소창에 입력합니다. 보낼 패킷의 HTTP 헤더는, HTTP Request 를 통해 채워진 상태입니다. 보낼 패킷의 IP 헤더를 채우기 위해, DNS 서버를 통해 www.google.com 도메인의 IP 주소를 응답 받습니다. 보낼 패킷의 TCP 헤더를 채우기 위해, 클라이언트와 구글 웹서버 간 TCP 연결을 합니다. 3-Way Handshaking 보낼 패킷이 완성되었으므..