PRDEN

1. 메시지 헤더 : HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함되어 있다. 메시지 헤더에는 클라이언트나 서버가 리퀘스트 리스폰스를 처리하기 위한 정보가 들어있다. 그리고 메시지 바디의 크기나 사용하고 있는 언어, 인증 정보 등을 브라우저나 서버에 제공하기 위해 사용된다. 예를 들어 Content-Type:text/html이라는 메시지 바디의 오브젝트 타입을 가리키는 헤더 필드가 있다. 2. Keep-Alive에 관하여 Http는 state less이며 connection less이다. 따라서 데이터를 주고받을 때마다 열고 닫고를 반복하는데 Keep-Alive를 설정하면 데이터를 지정한 시간 내에 지정한 횟수 내에서 데이터를 빈번하게 주고받을 수 있다. 1) Keep-Alive의..

1. 통신을 중계하는 프로그램 : 1) 프록시 서버 : 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고 서버로부터의 리스폰스를 클라이언트에 전송한다. a. 캐싱 프록시 : 프록시로 리스폰스를 중계하는 때 프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시이다. 프록시에 다시 같은 리소스에 리퀘스트가 온 경우, 오리진 서버로부터 리소스를 획득하는 것이 아니라 캐시를 리스폰스로 돌려주는 것이 있다. 그러나 캐시에도 유효기간이 있어서 캐시서버에서 오리진 서버로 새로운 리소스를 획득하러 가는 경우도 있다. * 캐시 서버뿐만 아니라 클라이언트 측에도 캐시가 존재한다. b. 투명 프록시 : 프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는..

3장은 특별한 내용 없다. Request와 Respose 메시지에 대해서는 :https://prde.tistory.com/81 Http와 REST 1. Http 프로토콜 HTTP 메시지 프로토콜은 반드시 request/response의 한쌍으로 구성되어있다. 그리고 request와 response는 각각 header와 body로 이루어져 있고 header와 body 사이에는 반드시 한 줄이 띄.. prde.tistory.com 1. 상태 코드 1) 2XX (성공) 204 : 리퀘스트를 성공했지만 돌려줄 리소스 없을 경우 : 클라이언트에서 서버로 정보를 보내는 것으로 족하고, 클라이언트에 새로운 정보를 보낼 필요가 없는 경우 사용 206 : 이 리스폰스는 Content-Range로 지정된 범위의 엔티티가 ..

1. Request와 Response 1) Request 메시지 구성 2) Response 메시지 구성 2. HTTP 프로토콜의 특징 1) HTTP는 상태를 유지하지 않는 stateless 프로토콜이다. HTTP 프로토콜 독자적으로 Request와 Response를 교환하는 동안에 상태를 관리하지 않는다. 이를 보완하기 위해 쿠키가 등장(쇼핑몰에서 로그인 후 다른 사이트로 이동해도 로그인 상태 유지되도록) 2) URI를 통해 인터넷 상의 어떤 장소에 있는 리소스도 호출할 수 있다. ( 모든 URI를 리퀘스트 URI에 포함하거나 Host 헤더 필드에 네트워크 로케이션을 포함하거나) 3) HTTP 메서드 a. GET : 리소스 획득 메서드이다. b. POST : 엔티티 전송 메소드 c. PUT : 파일 전송..

1. HTTP 1) WWW(World Wide Web)를 구성하는 기술로는 SGML을 베이스로 한 HTML, 문서 전송 프로토콜로는 HTTP, 문서의 주소를 지정하는 방법으로URL 등세 가지로 제안되었다. 2.TCP/IP 1) 컴퓨터와 네트워크 기기가 상호 간에 통신하기 위해 서로 같은 방법으로 통신해야 한다. 이러한 규칙을 '프로토콜'이라고 한다. 2) 프로토콜에는 a. 케이블 규격과 IP주소 지정 방법 b. 떨어진 상태를 찾기 위한 방법 c. 그곳에 도달하는 순서 d. 웹을 표시하기 위한 순서와 같은 여러 가지가 있다. 3) TCP/IP는 애플리케이션 계층, 트랜스포트 계층, 데이터링크 계층, 링크 계층으로 나뉘어 있다. a. 애플리케이션 계층 : 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움..

1. 웹과 네트워크의 기본 https://prde.tistory.com/98?category=959443 2. 간단한 HTTP 프로토콜 https://prde.tistory.com/99?category=959443 4. 결과를 전달하는 HTTP 상태코드 https://prde.tistory.com/102 5. HTTP와 연계하는 웹 서버 https://prde.tistory.com/104 6. HTTP 헤더 7. 웹을 안전하게 하는 HTTPS https://prde.tistory.com/108 8. 누가 엑세스 하고 있는지를 확인하는 인증 https://prde.tistory.com/109?category=959443 9. HTTP에 기능을 추가한 프로토콜 / 10. 웹 콘텐츠에서 사용하는 기술 http..

설계 원칙 : SOLID 1. 단일 책임원칙: 1) 단일 책임 원칙 (클래스는 단 한 개의 책임을 가져야 한다.) : 다른 말로 클래스를 변경하는 이유는 단 한 개여야 한다. 그러나 하나의 책임의 개념이 명확하지 않고, 하나의 책임을 도출하려면 많은 경험이 필요하기 때문에 어려운 원칙이다. 2) 단일 책임원칙 위반 시 불러오는 문제점 : 예를 들어 데이터를 읽는 책임과 데이터를 화면에 출력하는 책임 2가지를 동시에 하나의 클래스에서 관리하면, 책임의 개수가 많아질수록 책임의 기능 변화가 다른 책임에 주는 영향이 비례해서 증가해서 결국 코드를 절차 지향적으로 만든다. 이는 유지보수, 재사용의 어려움을 야기한다. 3) 책임이란 변화에 대한 것 : 단일 책임 원칙을 잘 지킬 수 있는 방법은 메서드를 실행하는 ..

재사용 측면에서 1. 상속의 단점 : (변경의 유연함의 측면에서 치명적인 단점을 갖는다.) 1) 상위 클래스 변경의 어려움 : 상위 클래스를 변경할 경우 하위 클래스에 영향을 주게 된다. 따라서 클래스 계층도가 커질수록 상위 클래스를 변경하는 것은 점점 어려워진다. 2) 클래스 수의 불필요한 증가 : 예를 들어 Storage 클래스를 상속받아 CompressedStorage 클래스와 EncryptedStorage 클래스를 추가했다 가정하자. 이 상황에서 압축을 먼저 하고 암호화하는 저장소가 필요하다면 CompressedEncryptedStorage를 추가해야 하고, 암호화를 먼저 하고 압축을 해야 하는 저장소가 필요하면 EncryptedCompressedStorage를 추가해야 한다. 또한, 추가적으로 ..

part1. 객체지향 1-1. 들어가기 1-2. 객체지향 1-3. 다형성과 추상화 1-4. 재사용 : 상속보다는 조립 part2. 설계원칙 / DI와 서비스 로케이터 2-1. 설계원칙 : SOLID 2-1. DI와 서비스 로케이터 part3. 주요 디자인 패턴

책의 6~10장에서는 애플리케이션 개발자를 대상으로 대규모 데이터를 처리하는 핵심 요소를 파악하도록 하기 위해 지금까지 소개했던 각종 방법을 자세히 들여다본다. 6장에서는 과제로서 압축 프로그래밍, 7,8장에서는 알고리즘, 데이터의 실용화 9장, 10장에서는 검색엔진을 만든다. 1. 정수 데이터를 컴팩트하게 가져가기 1) 과제 : 정수열이 기록된 CSV를 바이너리로 해서 콤팩트하게 가져가기 : 정수의 부호화를 연구해서 텍스트로 152MB인 CSV 데이터를 절반 이하의 크리로 처리할 수 있도록 하라. 물론 원본을 복원할 수 있어야 한다. 2) 출제의도 : 큰데이터를 압축해서 콤팩트하게 만들면 디스크 I/O를 줄일 수 있다. (큰 데이터를 다룰 때 '압축'을 항상 염두에 두어라) 또한 RDBMS에서 보통 정..