본문 바로가기

CS 과목(CS科目）

HTTP 메서드(PUT vs POST) PUT vs Post-> Post는 "서버"에서 리소스의 위치를 알고 있지만, PUT은 "클라이언트"가 알고 있어야 한다. EX) POST /members : 서버에 신규 회원 리소스를 등록(리소스의 등록 위치는 서버가 결정!!)      PUT /members/100 : 클라이언트가 리소스의 위치(100)을 이미 알고 있다.(혹은 리소스가 등록될 위치를 클라이언트가지정 가능) *PATCH 메서드는 일부 서버에서는 지원이 안 된다고 한다. 그런 경우에는 POST 메서드 사용을 권장! 더보기
비연결성,Connectionless(모든 개발자를 위한 HTTP) 비연결성(Connectionless) : 대단한 것은 아니고, 클라이언트가 요청을 보내고 그에 대한 응답을 보내는 즉시 연결(주로TCP연결)을 끊어 버리는 것을 뜻함->  비연결성(Connectionless)의 장점은 여러 클라이언트와 HTTP 통신을 맺을 때 서버의 네트워크 관련 리소스를 매우 효율적으로 관리할 수 있기 때문이다. 이러한 비연결성(Connectionless) 덕분에 대규모 트래픽을 처리할 수 있는 것이다. 일반적으로 초 단위 이하의 빠른 속도로 응답이 이루어 진다.그리고 [정확히 동시에]에 웹 요청이 들어오는 경우는 수십 명이 안 된다(그래서 1시간 동안 수천명이 서비스를 사용해도실제 서버에서 [동시에] 처리하는 요청은 수십개 이하로 매우매우 작음).또한 우리는 웹 브라우저에서 계속 연.. 더보기
HTTP(모든 개발자를 위한 HTTP 웹 기본 지식) HTTP/1.1 : 현재 가장 많이 사용 중인 HTTP 버전(크롬은 이미 UDP 기반의 HTTP/3.0을 쓰고 있다)HTTP 특징1] 클라이언트 서버 구조2] 무상태 프로토콜(Stateless), 비연결성-> 상태(Stateful) 유지 프로토콜 : 중간에 다른 서버로 바뀌면 안 된다는 약속(만약 바꾸게 되면 중간에 다른 서버로 바뀔 때마다 그 서버에게 상태 정보를 다 전달해야 하는 치명적인 문제점이 있다)-> 무상태(Stateless) 프로토콜 : 중간에 얼마든지 다른 서버로 바뀌어도 된다.(애초에 클라이언트가 서버에게 요청을 할 때 HTTP 요청에 서버가 필요한 모든 데이터를 담아서 보낸다. 고로, 서버가 중간에 셧다운이 되어도 서버가 필요로 하는 모든 데이터를 담은 해당 요청을 다른 서버에게 보내어.. 더보기
TCP/UDP(모든 웹 개발자를 위한 HTTP) [TCP/UDP 프로토콜 강의 메모] IP 프로토콜의 한계 -> 아래의 TCP가 필요한 이유와 연결지어서 생각!!! TCP의 역할(IP 프로토콜의 한계를 극복해준다,대부분의 애플리케이션에서 TCP 사용) 1. IP(목적지 컴퓨터) 주소의 컴퓨터가 네트워크 통신을 할 준비가 돼 있는 지 [연결성 보장(연결 지향적)] -> 3way handshake -> 가상 연결 : 물리적 연결이 아닌 개념적 연결  클라이언트와 서버 사이에는 수 많은 노드들(라우터들)이 있다. 이 라우터들은 클라이언트와 서버 사이의 데이터 전송로를 만들어 놓지 않기 때문에 물리적으로 연결돼 있다고 말할 수 없다.  (옛날에는 전화 교환원이 전화선 PORT를 직접 꽂음으로서 물리적인 연결로 통신을 했다) 2. 전송 [패킷의 순서를 보장] .. 더보기
MQ,MFQ 스케줄링 MQ Multilevel Queue Scheduling MQ알고리즘은 프로세스가 쉽게 다른 그룹으로 분류되는 환경을 위한 것이다. MQ partition은 여러개의 분할된 레디큐로 되어 있다. 각 큐에서 그들만의 스케줄링을 사용한다. 위 사진의 5개의 프로세스 집단에 각각 큐를 할당하여 각 큐에서 스케줄링을 한다. 단점으로 큐를 스케줄링하는 것이 필요하다는 것이 있다. 장점으로는 그룹화를 하여 CPU bound와 I/O bound가 섞여서 효율이 안 좋은 것을 막을 수 있다. 이 MQ의 단점을 해결하는 것이 MFQ이다. MFQ Mulrilevel Feedback Queue Scheduling MQ알고리즘은 스케줄링 오버헤드가 낮다는 장점이 있지만 융통성이 없다. 어떤 큐는 비어서 놀고 있고, 어떤 큐는 .. 더보기
SSL Protocol의 구체적 동작 방식 결론부터 말하면 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용한다. ( 공개키는 사실 상당한 컴퓨팅 파워를 필요로 한다 고로, 공개키만을 사용하지 않고, 대칭키와 혼합을 하여 사용) 즉 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호 화할 때사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다. 이 설명만으로는 이해하기 어려울 것이다. 아래의 관계만 일단 머리속에 기억해두고 좀 더 구체적인 설명으로 넘어가자.(아래에서 자세히 설명함) 실제 데이터(비밀번호 등..) : 대칭키로 암호화를 해서 전송하고, 같은 대칭키로 복호화를 한다. (클라이언트, 서버는 대칭키를 공유하고 있어야 한다) 대칭키.. 더보기
SSL Protocol의 요약본 공개키 ; 클라이언트에게 넘겨서, 공개키를 가지고 [암호화]해라 비밀키 : 암호화된 데이터가 전송이 되면, 복호화(절대로 유출해서는x) SSL 인증서의 내용 및 역할 1. 서버의 공개키 2. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등등) 3. 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장한다. 4. SSL 통신에 사용할 공개키를 클라이언트에게 제공한다 서버와 클라이언트 간의 SSL Protocol은 [핸드 쉐이킹] 과정에서 이루어 진다. 1 클라이언트는 [인증서]로부터 서버의 [공개키] 획득 2. 세션 단계에서 데이터를 암호화하기 위한 pre master key를 클라이언트가 생성 3. pre master key를 서버의 [공개키]로 암호화 하여, 서버에 전송 4. 서버는 비.. 더보기
SSL 인증서의 서비스 보증 방법 이번 절을 시작할 때 인증서의 첫번째 목적을 아래와 같이 언급했다. 어떤 메커니즘으로 인증서가 서버의 신뢰성을 보장하는지 알아보자. 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공한다. 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지를 확인한다. 확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화 한다. CA의 공개키를 이용해서 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미한다. 해당 CA의 비공개 키를 가지고 있는 CA는 해당 CA 밖에는 없기 때문에 서버가 제공한 인증서가 CA에.. 더보기

티스토리툴바