├── .gitignore ├── README.md └── contents ├── algorithm.md ├── datastructure.md ├── db.md ├── designpattern.md ├── etc.md ├── images ├── 3-way-handshaking.png ├── 4-way-handshaking.png ├── BigO-complexity-chart.png ├── JVMHeap.png ├── access-controller.png ├── b-async.png ├── bfs-example.png ├── bfs-vs-dfs.gif ├── blocking.png ├── cookie-process.png ├── cross-join.png ├── data-access-layer.png ├── data-encapsulation.png ├── db-btree.png ├── db-img │ ├── db-connection-01.jpeg │ └── db-connection-02.png ├── db-index.png ├── dfs-example.png ├── equals-example.png ├── factory-method-pattern.png ├── filterInterceptor.jpg ├── full-outer-join.png ├── g1gc.png ├── generics.png ├── graph-vs-tree.png ├── hashtable.png ├── inner-join.png ├── isolation-level.png ├── java-collections-framework.png ├── java_boxing_unboxing.png ├── jdbc-component-interface-diagram.png ├── jdbc1.png ├── jdbc_basic_cycle.png ├── join-table.png ├── jvm-runtime-data-areas.png ├── left-outer-join.png ├── memcached-usage.png ├── multi-thread.png ├── natural-join.png ├── non-sync.png ├── osi-7-layer.png ├── osi-pdu.png ├── partitioning.png ├── persistence-layer.png ├── process.png ├── right-outer-join.png ├── separatingChaining.png ├── session-process.png ├── singleton-example.png ├── strategy-pattern.png ├── tcp-virtual-circuit.png ├── tcpheader.png ├── template-method-pattern.png ├── thread.png ├── transaction-status.png ├── types-of-designpattern.png ├── types-of-partitioning.png ├── udp-datagram.png └── udpheader.png ├── java.md ├── javascript.md ├── network.md ├── os.md ├── security.md ├── spring.md └── template.md /.gitignore: -------------------------------------------------------------------------------- 1 | # IntelliJ 2 | out/ 3 | out/* 4 | .idea/ 5 | *.iml 6 | .idea/* 7 | *.idea 8 | .idea/workspace.xml 9 | .idea/tasks.xml 10 | .idea/gradle.xml 11 | .idea/assetWizardSettings.xml 12 | .idea/dictionaries 13 | .idea/libraries 14 | .idea/caches 15 | 16 | # MacOS 17 | .DS_Store 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Tech Interview 2 | 3 | **기술 면접 대비를 위한 기본 개념을 정리하는 Repository 입니다.** 4 | > :star: 내용에 오류가 있거나 추가할 내용이 있다면 Pull Request를 통해서 알려주시면 감사하겠습니다. 5 | >
:star: Star나 Watching를 통한 많은 관심 부탁드립니다. :) 6 | 7 |
8 | 9 | [![author](https://img.shields.io/badge/author-WeareSoft-red.svg)](https://github.com/WeareSoft) 10 | [![HeeBlog](https://img.shields.io/badge/blog-Hee-lightgrey.svg)](https://gmlwjd9405.github.io/) 11 | [![DoyBlog](https://img.shields.io/badge/blog-Doy-lightgrey.svg)](https://doooyeon.github.io/) 12 | [![NesoyBlog](https://img.shields.io/badge/blog-Nesoy-lightgrey.svg)](https://nesoy.github.io/) 13 | [![DelfBlog](https://img.shields.io/badge/blog-Delf-lightgrey.svg)](https://delf-lee.github.io/) 14 | [![contributors](https://img.shields.io/badge/contributors-4-yellowgreen.svg)](https://github.com/WeareSoft/tech-interview/graphs/contributors) 15 | [![HitCount](http://hits.dwyl.io/WeareSoft/tech-interview.svg?style=popout)](http://hits.dwyl.io/WeareSoft/tech-interview) 16 | 17 |
18 | 19 | 20 | **:book: Contents** 21 | 1. [Data Structure](#1-data-structure) 22 | 2. [Network](#2-network) 23 | 3. [Operating System](#3-operating-system) 24 | 4. [Database](#4-database) 25 | 5. [Design Pattern](#5-design-pattern) 26 | 6. [Algorithm](#6-algorithm) 27 | 7. [Java](#7-java) 28 | 8. [JavaScript](#8-javascript) 29 | 9. [Spring](#9-spring) 30 | 10. [Security](#10-security) 31 | 11. [ETC](#11-etc) 32 | 33 | --- 34 | 35 | ## 1. Data Structure 36 | :arrow_forward: [답변 내용](/contents/datastructure.md) 37 | * Array 38 | * LinkedList 39 | * HashTable 40 | * Stack 41 | * Queue 42 | * Graph 43 | * Tree 44 | * 그래프(Graph)와 트리(Tree)의 차이점 45 | * Binary Heap 46 | * Red-Black Tree 47 | * B+ Tree 48 | 49 | ## 2. Network 50 | :arrow_forward: [답변 내용](/contents/network.md) 51 | * OSI 7계층 52 | * TCP/IP의 개념 53 | * TCP와 UDP 54 | * TCP와 UDP의 헤더 분석 55 | * TCP의 3-way-handshake와 4-way-handshake 56 | * Q. TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유? 57 | * Q. 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까? 58 | * Q. 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유? 59 | * HTTP와 HTTPS 60 | * HTTP 요청/응답 헤더 61 | * HTTP와 HTTPS 동작 과정 62 | * CORS란 63 | * GET 메서드와 POST 메서드 64 | * 쿠키(Cookie)와 세션(Session) 65 | * DNS 66 | * REST와 RESTful의 개념 67 | * 소켓(Socket)이란 68 | * Socket.io와 WebSocket의 차이 69 | * Frame, Packet, Segment, Datagram 70 | 71 | ## 3. Operating System 72 | :arrow_forward: [답변 내용](/contents/os.md) 73 | * 프로세스와 스레드의 차이(Process vs Thread) 74 | * 멀티 프로세스 대신 멀티 스레드를 사용하는 이유 75 | * Thread-safe 76 | * 동기화 객체의 종류 77 | * 뮤텍스와 세마포어의 차이 78 | * 스케줄러 79 | * 동기와 비동기 80 | * 프로세스 동기화 81 | * 메모리 관리 전략 82 | * 가상 메모리 83 | * 캐시의 지역성 84 | * 교착상태(데드락, Deadlock)의 개념과 조건 85 | * 사용자 수준 스레드와 커널 수준 스레드 86 | * 외부 단편화와 내부 단편화 87 | * Context Switching 88 | * Swapping 89 | 90 | ## 4. Database 91 | :arrow_forward: [답변 내용](/contents/db.md) 92 | * 데이터베이스 풀 93 | * 정규화(1차 2차 3차 BCNF) 94 | * 트랜잭션(Transaction) 이란 95 | * 트랜잭션 격리 수준(Transaction Isolation Level) 96 | * Join 97 | * SQL injection 98 | * Index란 99 | * Statement와 PrepareStatement 100 | * RDBMS와 NoSQL 101 | * 효과적인 쿼리 저장 102 | * 옵티마이저(Optimizer)란 103 | * Replication 104 | * 파티셔닝(Partitioning) 105 | * 샤딩(Sharding) 106 | * 객체 관계 매핑(Object-relational mapping, ORM)이란 107 | * java JDBC 108 | 109 | ## 5. Design Pattern 110 | :arrow_forward: [답변 내용](/contents/designpattern.md) 111 | * 디자인 패턴의 개념과 종류 112 | * Singleton 패턴 113 | * Strategy 패턴 114 | * Template Method 패턴 115 | * Factory Method 패턴 116 | * MVC1 패턴과 MVC2 패턴 117 | 118 | ## 6. Algorithm 119 | ### :pushpin: [관련 링크](https://github.com/WeareSoft/algorithm-study) 120 | :arrow_forward: [답변 내용](/contents/algorithm.md) 121 | * BigO 122 | * DFS와 BFS의 차이 123 | * Fibonacci에서의 세 가지(Recursion, Dynamic Programming, 반복) 방식에 대한 시간복잡도와 공간복잡도 차이 124 | * 정렬 알고리즘의 종류와 개념 125 | * Greedy 알고리즘 126 | * 최소 신장 트리(MST, Minimum Spanning Tree)란 127 | * Kruskal MST 알고리즘 128 | * Prim MST 알고리즘 129 | 130 | ## 7. Java 131 | :arrow_forward: [답변 내용](/contents/java.md) 132 | * java 프로그래밍이란 133 | * Java SE와 Java EE 애플리케이션 차이 134 | * java와 c/c++의 차이점 135 | * java 언어의 장단점 136 | * java의 접근 제어자의 종류와 특징 137 | * java의 데이터 타입 138 | * Wrapper class 139 | * OOP의 4가지 특징 140 | * 추상화(Abstraction), 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism) 141 | * OOP의 5대 원칙 (SOLID) 142 | * 객체지향 프로그래밍과 절차지향 프로그래밍의 차이 143 | * 객체지향(Object-Oriented)이란 144 | * java의 non-static 멤버와 static 멤버의 차이 145 | * Q. java의 main 메서드가 static인 이유 146 | * java의 final 키워드 (final/finally/finalize) 147 | * java의 제네릭(Generic)과 c++의 템플릿(Template)의 차이 148 | * java의 가비지 컬렉션(Garbage Collection) 처리 방법 149 | * java 직렬화(Serialization)와 역직렬화(Deserialization)란 무엇인가 150 | * 클래스, 객체, 인스턴스의 차이 151 | * 객체(Object)란 무엇인가 152 | * 오버로딩과 오버라이딩의 차이(Overloading vs Overriding) 153 | * Call by Reference와 Call by Value의 차이 154 | * 인터페이스와 추상 클래스의 차이(Interface vs Abstract Class) 155 | * JVM 구조 156 | * Java Collections Framework 157 | * java Map 인터페이스 구현체의 종류 158 | * java Set 인터페이스 구현체의 종류 159 | * java List 인터페이스 구현체의 종류 160 | * Annotation 161 | * String, StringBuilder, StringBuffer 162 | * 동기화와 비동기화의 차이(Syncronous vs Asyncronous) 163 | * java에서 '=='와 'equals()'의 차이 164 | * java의 리플렉션(Reflection) 이란 165 | * Stream이란? 166 | * Lambda란? 167 | 168 | ## 8. JavaScript 169 | :arrow_forward: [답변 내용](/contents/javascript.md) 170 | * JavaScript Event Loop 171 | * 함수 선언식과 함수 표현식 172 | * 화살표 함수(Arrow Function) 173 | * 향상된 객체 리터럴(Enhanced Object Literals) 174 | * Modules 175 | * 디스트럭처링(Destructuring) 176 | * 전개 연산자(Spread Operator) 177 | * 호이스팅(Hoisting) 178 | * Closure 179 | * this 180 | * Promise 181 | * Async/Await 182 | 183 | ## 9. Spring 184 | :arrow_forward: [답변 내용](/contents/spring.md) 185 | * 스프링 프레임워크란 186 | * Spring, Spring MVC, Spring Boot의 차이 187 | * Bean이란 188 | * Container란 189 | * IOC(Inversion of Control, 제어의 역전)란 190 | * MVC 패턴이란 191 | * DI(Dependency Injection, 의존성 주입)란 192 | * AOP(Aspect Oriented Programming)란 193 | * POJO 194 | * DAO와 DTO의 차이 195 | * Spring JDBC를 이용한 데이터 접근 196 | * Filter와 Interceptor 차이 197 | 198 | ## 10. Security 199 | :arrow_forward: [답변 내용](/contents/security.md) 200 | * 대칭키와 비대칭키 차이 201 | * 패스워드 암호화 방법 202 | * SQL Injection 공격 203 | * CSRF 공격 204 | * XSS 공격 205 | * OAuth 206 | 207 | ## 11. ETC 208 | :arrow_forward: [답변 내용](/contents/etc.md) 209 | * TDD란 210 | * 웹 브라우저에서 서버로 어떤 페이지를 요청하면 일어나는 일련의 과정을 설명 211 | * Ex. url에 'www.naver.com' 을 입력했다. 일어나는 현상에 대해 아는대로 설명하라. 212 | * 컴파일러와 인터프리터 213 | * 분산락 214 | * 프레임워크와 라이브러리의 차이 215 | * 64bit CPU와 32bit CPU 차이 216 | * CVS, SVN, Git 217 | * Git Branch 종류(5가지) 218 | * 웹 서버(Web Server)와 웹 어플리케이션 서버(WAS)의 차이 219 | * 애자일 방법론이란 220 | * Servlet과 JSP 221 | * Redis와 Memcached의 차이 222 | * Maven과 Gradle의 차이 223 | * Blocking과 Non-Blocking 224 | * 함수형 프로그래밍이란 225 | * 이벤트 기반 프로그래밍이란 226 | * Mock이란 227 | 228 | --- 229 | 230 | # Reference 231 | * [jojoldu님의 junior-recruit-scheduler](https://github.com/jojoldu/junior-recruit-scheduler/blob/master/README.md) 232 | * [JaeYeopHan 님의 Interview_Question_for_Beginner](https://github.com/JaeYeopHan/Interview_Question_for_Beginner) 233 | * [KimHunJin님의 Study-Book/interview](https://github.com/KimHunJin/Study-Book/tree/master/interview) 234 | * [TaeMInMoon님의 신입 개발자 기술면접](https://trello.com/b/BWtpfywH/%EC%8B%A0%EC%9E%85-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EA%B8%B0%EC%88%A0%EB%A9%B4%EC%A0%91) 235 | * [NESOY님의 Back-end-Developer-Interview-Questions](https://github.com/NESOY/Back-end-Developer-Interview-Questions) 236 | * [hanee24님의 신입 개발자 면접 질문](https://hanee24.github.io/2018/05/13/interview-questions/) 237 | * [“개발자 면접 예상 질문, 오픈소스로 공유해요”](http://www.bloter.net/archives/246472) 238 | * [150 Java Interview Questions and Answers](https://www.javacodegeeks.com/2014/04/java-interview-questions-and-answers.html#2) 239 | * [yangshun님의 front-end-interview-handbook](https://github.com/yangshun/front-end-interview-handbook/blob/master/Translations/Korean/questions/javascript-questions.md) 240 | * [ganqqwerty님의 123-Essential-JavaScript-Interview-Questions](https://github.com/ganqqwerty/123-Essential-JavaScript-Interview-Questions) 241 | -------------------------------------------------------------------------------- /contents/algorithm.md: -------------------------------------------------------------------------------- 1 | # 6. Algorithm 2 | **:book: Contents** 3 | * [BigO](#bigo) 4 | * [DFS와 BFS의 차이](#dfs와-bfs의-차이) 5 | * [Fibonacci에서의 세 가지(Recursion, Dynamic Programming, 반복) 방식에 대한 시간복잡도와 공간복잡도 차이](#fibonacci에서의-재귀-동적프로그래밍-반복의-세-가지-방식에-대한-시간복잡도와-공간복잡도) 6 | * [정렬 알고리즘의 종류와 개념](#정렬-알고리즘의-종류와-개념) 7 | * [Greedy 알고리즘](#greedy-알고리즘) 8 | * [최소 신장 트리(MST, Minimum Spanning Tree)란](#mst란) 9 | * [Kruskal MST 알고리즘](#kruskal-mst-알고리즘) 10 | * [Prim MST 알고리즘](#prim-mst-알고리즘) 11 | --- 12 | 13 | ### BigO 14 | * BigO의 개념 15 | * BigO의 복잡성 차트 보기 16 | * 17 | * -> [http://bigocheatsheet.com/](http://bigocheatsheet.com/) 18 | 19 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 20 | > - []() 21 | 22 | ### DFS와 BFS의 차이 23 | ![](https://github.com/WeareSoft/tech-interview/blob/master/contents/images/bfs-vs-dfs.gif) 24 | 25 | * 깊이 우선 탐색(DFS, Depth-First Search) 26 | * DFS의 개념: 루트 노드(혹은 다른 임의의 노드)에서 시작해서 다음 분기(branch)로 넘어가기 전에 해당 분기를 완벽하게 탐색하는 방법 27 | * 미로를 탐색할 때 한 방향으로 갈 수 있을 때까지 계속 가다가 더 이상 갈 수 없게 되면 다시 가장 가까운 갈림길로 돌아와서 이곳으로부터 다른 방향으로 다시 탐색을 진행하는 방법과 유사하다. 28 | * 즉, 넓게(wide) 탐색하기 전에 깊게(deep) 탐색하는 것이다. 29 | * 사용하는 경우: **모든 노드를 방문** 하고자 하는 경우에 이 방법을 선택한다. 30 | * 깊이 우선 탐색(DFS)이 너비 우선 탐색(BFS)보다 좀 더 간단하다. 31 | * 단순 검색 속도 자체는 너비 우선 탐색(BFS)에 비해서 느리다. 32 | * DFS의 특징 33 | * 자기 자신을 호출하는 **순환 알고리즘의 형태** 를 가지고 있다. 34 | * 전위 순회(Pre-Order Traversals)를 포함한 다른 형태의 트리 순회는 모두 DFS의 한 종류이다. 35 | * 이 알고리즘을 구현할 때 가장 큰 차이점은, 그래프 탐색의 경우 **어떤 노드를 방문했었는지 여부를 반드시 검사** 해야 한다는 것이다. 36 | * 이를 검사하지 않을 경우 무한루프에 빠질 위험이 있다. 37 | * DFS의 과정 38 | * 39 | * DFS의 구현 방법 2가지 40 | * **1. 순환 호출 이용** 41 | 42 | * **2. 명시적인 스택 사용** 43 | * 명시적인 스택을 사용하여 방문한 정점들을 스택에 저장하였다가 다시 꺼내어 작업한다. 44 | * 순환 호출을 이용한 DFS 의사코드(pseudocode) 45 | ```java 46 | void search(Node root) { 47 | if (root == null) return; 48 | 49 | // 1. root 노드 방문 50 | visit(root); 51 | root.visited = true; // 1-1. 방문한 노드를 표시 52 | 53 | // 2. root 노드와 인접한 정점을 모두 방문 54 | for each (Node n in root.adjacent) { 55 | if (n.visited == false) { // 4. 방문하지 않은 정점을 찾는다. 56 | search(n); // 3. root 노드와 인접한 정점 정점을 시작 정점으로 DFS를 시작 57 | } 58 | } 59 | } 60 | ``` 61 | * 너비 우선 탐색(BFS, Breadth-First Search) 62 | * BFS의 개념: 루트 노드(혹은 다른 임의의 노드)에서 시작해서 인접한 노드를 먼저 탐색하는 방법 63 | * 시작 정점으로부터 가까운 정점을 먼저 방문하고 멀리 떨어져 있는 정점을 나중에 방문하는 순회 방법이다. 64 | * 즉, 깊게(deep) 탐색하기 전에 넓게(wide) 탐색하는 것이다. 65 | * 사용하는 경우: **두 노드 사이의 최단 경로** 혹은 **임의의 경로를 찾고 싶을 때** 이 방법을 선택한다. 66 | * Ex) 지구상에 존재하는 모든 친구 관계를 그래프로 표현한 후 Ash와 Vanessa 사이에 존재하는 경로를 찾는 경우 67 | * 깊이 우선 탐색의 경우 - 모든 친구 관계를 다 살펴봐야 할지도 모른다. 68 | * 너비 우선 탐색의 경우 - Ash와 가까운 관계부터 탐색 69 | * 너비 우선 탐색(BFS)이 깊이 우선 탐색(DFS)보다 좀 더 복잡하다. 70 | * BFS의 특징 71 | * 직관적이지 않은 면이 있다. 72 | * BFS는 시작 노드에서 시작해서 거리에 따라 단계별로 탐색한다고 볼 수 있다. 73 | * BFS는 **재귀적으로 동작하지 않는다.** 74 | * 이 알고리즘을 구현할 때 가장 큰 차이점은, 그래프 탐색의 경우 **어떤 노드를 방문했었는지 여부를 반드시 검사** 해야 한다는 것이다. 75 | * 이를 검사하지 않을 경우 무한루프에 빠질 위험이 있다. 76 | * BFS는 방문한 노드들을 차례로 저장한 후 꺼낼 수 있는 자료 구조인 **큐(Queue)를 사용한다.** 77 | * 즉, **선입선출(FIFO)** 원칙으로 탐색 78 | * 일반적으로 큐를 이용해서 반복적 형태로 구현하는 것이 가장 잘 동작한다. 79 | * 'Prim', 'Dijkstra' 알고리즘과 유사하다. 80 | * BFS의 과정 81 | * 깊이가 1인 모든 노드를 방문하고 나서 그 다음에는 깊이가 2인 모든 노드를, 그 다음에는 깊이가 3인 모든 노드를 방문하는 식으로 계속 방문하다가 더 이상 방문할 곳이 없으면 탐색을 마친다. 82 | * 83 | * BFS의 구현 방법 84 | * 자료 구조 **큐(Queue)를 이용** 85 | * 큐(Queue)를 이용한 BFS 의사코드(pseudocode) 86 | ```java 87 | void search(Node root) { 88 | Queue queue = new Queue(); 89 | root.marked = true; // (방문한 노드 체크) 90 | queue.enqueue(root); // 1-1. 큐의 끝에 추가 91 | 92 | // 3. 큐가 소진될 때까지 계속한다. 93 | while (!queue.isEmpty()) { 94 | Node r = queue.dequeue(); // 큐의 앞에서 노드 추출 95 | visit(r); // 2-1. 큐에서 추출한 노드 방문 96 | // 2-2. 큐에서 꺼낸 노드와 인접한 노드들을 모두 차례로 방문한다. 97 | foreach (Node n in r.adjacent) { 98 | if (n.marked == false) { 99 | n.marked = true; // (방문한 노드 체크) 100 | queue.enqueue(n); // 2-3. 큐의 끝에 추가 101 | } 102 | } 103 | } 104 | } 105 | ``` 106 | 107 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 108 | > - [https://gmlwjd9405.github.io/2018/08/14/algorithm-dfs.html](https://gmlwjd9405.github.io/2018/08/14/algorithm-dfs.html) 109 | > - [https://gmlwjd9405.github.io/2018/08/15/algorithm-bfs.html](https://gmlwjd9405.github.io/2018/08/15/algorithm-bfs.html) 110 | 111 | ### Fibonacci에서의 재귀 동적프로그래밍 반복의 세 가지 방식에 대한 시간복잡도와 공간복잡도 112 | 1. 재귀 113 | 2. 동적 프로그래밍 114 | 3. 반복 115 | 116 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 117 | > - []() 118 | 119 | ### 정렬 알고리즘의 종류와 개념 120 | * [버블 정렬(Bubble Sort)](https://gmlwjd9405.github.io/2018/05/06/algorithm-bubble-sort.html) 121 | * [삽입 정렬(insertion sort)](https://gmlwjd9405.github.io/2018/05/06/algorithm-insertion-sort.html) 122 | * [선택 정렬(selection sort)](https://gmlwjd9405.github.io/2018/05/06/algorithm-selection-sort.html) 123 | * [합병 정렬(merge sort)](https://gmlwjd9405.github.io/2018/05/08/algorithm-merge-sort.html) 124 | * [퀵 정렬(quick sort)](https://gmlwjd9405.github.io/2018/05/10/algorithm-quick-sort.html) 125 | * [힙 정렬(heap sort)](https://gmlwjd9405.github.io/2018/05/10/algorithm-heap-sort.html) 126 | * [셸 정렬(shell sort)](https://gmlwjd9405.github.io/2018/05/08/algorithm-shell-sort.html) 127 | * 정렬 알고리즘의 애니메이션 보기 128 | * -> [https://www.toptal.com/developers/sorting-algorithms](https://www.toptal.com/developers/sorting-algorithms) 129 | 130 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 131 | 132 | ### Greedy 알고리즘 133 | - 탐욕법 134 | - 문제 해결 과정에서 순간순간마다 최적이라고 판단한 방식으로 진행하여 답에 도달 135 | - 문제의 성질이 동일하게 보존되고, 같은 전략을 반복적으로 사용 가능할 때 적용 136 | - 앞의 선택이 이후의 선택의 영향을 주지 않는 조건 137 | - 문제 최종 해결 방법이 부분 문제에 대한 해결 방법과 동일한 조건 138 | - 장점 139 | - 다른 최적해 계산 알고리즘에 비해 적은 비용 (빠른 속도) 140 | - 단점 141 | - 당장 그 순간의 최적 값을 찾기 때문에 항상 최적 해를 찾는 것은 불가능 142 | - 대표적인 그리디 알고리즘 문제 143 | - 주어진 각 동전을 가장 적게 사용해 N원을 만드는 문제 144 | - 일반적으로 동전은 보다 작은 금액 동전의 배수이기 때문에 작은 금액 동전을 무조건 큰 금액 동전으로 교체하는 것이 이득 145 | - 60원 동전이 생긴다면? 규칙이 깨지기 때문에 그리디 알고리즘 더이상 사용 불가 146 | - [도시락 문제](https://algospot.com/judge/problem/read/LUNCHBOX) 147 | - N개의 도시락을 단 한 대의 전자렌지에서 한 번에 하나만 데우기 가능하며, 각 도시락은 조리 시간과 먹는 시간이 다르게 정해져 있을 때 모든 도시락을 먹는데 걸리는 최소 시간 148 | - 먹는데 시간이 오래 걸리는 도시락부터 순서대로 데우면 가능 149 | - 이 외 첫번째 Reference 링크에서 추천 문제 참고 150 | 151 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 152 | > - [탐욕적 기법(Greedy Algorithm) (수정: 2019-11-23)](https://blog.naver.com/kks227/220775134486) 153 | > - [동적 계획법(Dynamic Programming)과 탐욕법(Greedy Algorithm)](https://velog.io/@cyranocoding/%EB%8F%99%EC%A0%81-%EA%B3%84%ED%9A%8D%EB%B2%95Dynamic-Programming%EA%B3%BC-%ED%83%90%EC%9A%95%EB%B2%95Greedy-Algorithm-3yjyoohia5) 154 | 155 | ### MST란 156 | * Spanning Tree란 157 | * 그래프 내의 모든 정점을 포함하는 트리, **Spanning Tree = 신장 트리 = 스패닝 트리** 158 | * Spanning Tree는 그래프의 **최소 연결 부분 그래프** 이다. 159 | * 최소 연결 = 간선의 수가 가장 적다. 160 | * n개의 정점을 가지는 그래프의 최소 간선의 수는 (n-1)개이고, (n-1)개의 간선으로 연결되어 있으면 필연적으로 트리 형태가 되고 이것이 바로 Spanning Tree가 된다. 161 | * 즉, 그래프에서 일부 간선을 선택해서 만든 트리 162 | * Spanning Tree의 사용 사례 163 | * 통신 네트워크 구축 164 | * 예를 들어, 회사 내의 모든 전화기를 가장 적은 수의 케이블을 사용하여 연결하고자 하는 경우 165 | * n개의 위치를 연결하는 통신 네트워크를 최소의 링크(간선)를 이용하여 구축하고자 하는 경우, 최소 링크의 수는 (n-1)개가 되고, 따라서 Spanning Tree가 가능해진다. 166 | * MST(Minimum Spanning Tree, 최소 신장 트리)란 167 | * Spanning Tree 중에서 사용된 간선들의 가중치 합이 최소인 트리, **MST = Minimum Spanning Tree = 최소 신장 트리** 168 | * 각 간선의 가중치가 동일하지 않을 때 단순히 가장 적은 간선을 사용한다고 해서 최소 비용이 얻어지는 것은 아니다. 169 | * MST는 간선에 가중치를 고려하여 최소 비용의 Spanning Tree를 선택하는 것을 말한다. 170 | * 즉, 네트워크(가중치를 간선에 할당한 그래프)에 있는 모든 정점들을 가장 적은 수의 간선과 비용으로 연결하는 것이다. 171 | * MST의 특징 172 | 1. 간선의 가중치의 합이 최소여야 한다. 173 | 2. n개의 정점을 가지는 그래프에 대해 반드시 (n-1)개의 간선만을 사용해야 한다. 174 | 3. 사이클이 포함되어서는 안된다. 175 | * MST의 사용 사례 176 | * 통신망, 도로망, 유통망에서 길이, 구축 비용, 전송 시간 등을 최소로 구축하려는 경우 177 | * 도로 건설: 도시들을 모두 연결하면서 도로의 길이가 최소가 되도록 하는 문제 178 | * 전기 회로: 단자들을 모두 연결하면서 전선의 길이가 가장 최소가 되도록 하는 문제 179 | * 통신: 전화선의 길이가 최소가 되도록 전화 케이블 망을 구성하는 문제 180 | * 배관: 파이프를 모두 연결하면서 파이프의 총 길이가 최소가 되도록 연결하는 문제 181 | 182 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 183 | > - [https://gmlwjd9405.github.io/2018/08/28/algorithm-mst.html](https://gmlwjd9405.github.io/2018/08/28/algorithm-mst.html) 184 | 185 | ### Kruskal MST 알고리즘 186 | * Kruskal MST 알고리즘이란 187 | * **탐욕적인 방법(greedy method)** 을 이용하여 네트워크(가중치를 간선에 할당한 그래프)의 모든 정점을 최소 비용으로 연결하는 최적 해답을 구하는 것 188 | * MST(최소 비용 신장 트리) 가 *1) 최소 비용의 간선으로 구성됨 2) 사이클을 포함하지 않음* 의 조건에 근거하여 **각 단계에서 사이클을 이루지 않는 최소 비용 간선을 선택** 한다. 189 | * 간선 선택을 기반으로 하는 알고리즘이다. 190 | * 이전 단계에서 만들어진 신장 트리와는 상관없이 무조건 최소 간선만을 선택하는 방법이다. 191 | * 과정 192 | 1. 그래프의 간선들을 가중치의 오름차순으로 정렬한다. 193 | 2. 정렬된 간선 리스트에서 순서대로 사이클을 형성하지 않는 간선을 선택한다. 194 | * 즉, 가장 낮은 가중치를 먼저 선택한다. 195 | * 사이클을 형성하는 간선을 제외한다. 196 | 3. 해당 간선을 현재의 MST(최소 비용 신장 트리)의 집합에 추가한다. 197 | 198 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 199 | > - [https://gmlwjd9405.github.io/2018/08/29/algorithm-kruskal-mst.html](https://gmlwjd9405.github.io/2018/08/29/algorithm-kruskal-mst.html) 200 | 201 | ### Prim MST 알고리즘 202 | * Prim MST 알고리즘이란 203 | * 시작 정점에서부터 출발하여 신장트리 집합을 **단계적으로 확장** 해나가는 방법 204 | * 정점 선택을 기반으로 하는 알고리즘이다. 205 | * 이전 단계에서 만들어진 신장 트리를 확장하는 방법이다. 206 | * 과정 207 | 1. 시작 단계에서는 시작 정점만이 MST(최소 비용 신장 트리) 집합에 포함된다. 208 | 2. 앞 단계에서 만들어진 MST 집합에 인접한 정점들 중에서 최소 간선으로 연결된 정점을 선택하여 트리를 확장한다. 209 | * 즉, 가장 낮은 가중치를 먼저 선택한다. 210 | 3. 위의 과정을 트리가 (N-1)개의 간선을 가질 때까지 반복한다. 211 | 212 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#6-algorithm) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 213 | > - [https://gmlwjd9405.github.io/2018/08/30/algorithm-prim-mst.html](https://gmlwjd9405.github.io/2018/08/30/algorithm-prim-mst.html) 214 | 215 | 216 | ## Reference 217 | > - [https://github.com/tayllan/awesome-algorithms](https://github.com/tayllan/awesome-algorithms) 218 | > - [https://www.cs.usfca.edu/~galles/visualization/Algorithms.html](https://www.cs.usfca.edu/~galles/visualization/Algorithms.html) 219 | 220 | 221 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 222 | -------------------------------------------------------------------------------- /contents/datastructure.md: -------------------------------------------------------------------------------- 1 | # 1. Data Structure 2 | **:book: Contents** 3 | * [Array](#array) 4 | * [LinkedList](#linkedlist) 5 | * [HashTable](#hashtable) 6 | * [Stack](#stack) 7 | * [Queue](#queue) 8 | * [Graph](#graph) 9 | * [Tree](#tree) 10 | * [그래프(Graph)와 트리(Tree)의 차이점](#그래프와-트리의-차이점) 11 | * [Binary Heap](#binary-heap) 12 | * [Red-Black Tree](#red-black-tree) 13 | * [B+ Tree](#B+-Tree) 14 | 15 | --- 16 | 17 | ### Array 18 | 19 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 20 | > - []() 21 | 22 | ### LinkedList 23 | 24 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 25 | > - []() 26 | 27 | ### HashTable 28 | 29 | * HashTable 개념 30 | * Key와 Value를 1:1로 연관지어 저장하는 자료구조 (연관배열 구조) 31 | * Key를 이용하여 Value 도출 32 | 33 | * HashTable 기능 34 | * 연관배열 구조와 동일한 기능 지원 35 | * Key, Value가 주어졌을 때, 두 값을 저장 36 | * Key가 주어졌을 때, 해당 Key에 연관된 Value 조회 37 | * 기존 Key에 새로운 Value가 주어졌을 때, 기존 Value를 새로운 Value로 대체 38 | * Key가 주어졌을 때, 해당 Key에 연관된 Value 제거 39 | 40 | * HashTable 구조 41 | 42 | ![hashtable](./images/hashtable.png) 43 | * Key, Hash Function, Hash, Value, 저장소(Bucket, Slot)로 구성 44 | * Key 45 | * 고유한 값 46 | * 저장 공간의 효율성을 위해 Hash Function에 입력하여 Hash로 변경 후 저장 47 | * Key는 길이가 다양하기 때문에 그대로 저장하면 다양한 길이만큼 저장소 구성이 필요 48 | * Hash Function 49 | * Key를 Hash로 바꿔주는 역할 50 | * 해시 충돌(서로 다른 Key가 같은 Hash가 되는 경우)이 발생할 확률을 최대한 줄이는 함수를 만드는 것이 중요 51 | * Hash 52 | * Hash Function의 결과 53 | * 저장소에서 Value와 매칭되어 저장 54 | * Value 55 | * 저장소에 최종적으로 저장되는 값 56 | * 키와 매칭되어 저장, 삭제, 검색, 접근 가능 57 | 58 | * HashTable 동작 과정 59 | 1. Key -> Hash Function -> Hash Function 결과 = Hash 60 | 2. Hash를 배열의 Index로 사용 61 | 3. 해당 Index에 Value 저장 62 | * HashTable 크기가 10이라면 A라는 Key의 Value를 찾을 때 hashFunction("A") % 10 연산을 통해 인덱스 값 계산하여 Value 조회 63 | 64 | * Hash 충돌 65 | * 서로 다른 Key가 Hash Function에서 중복 Hash로 나오는 경우 66 | * 충돌이 많아질수록 탐색의 시간 복잡도가 O(1)에서 O(n)으로 증가 67 | 68 | * Hash 충돌 해결 방법 69 | 1. Separating Chaining 70 | * JDK 내부에서 사용하는 충돌 처리 방식 71 | * Linked List(데이터 6개 이하) 또는 Red-Black Tree(데이터 8개 이상) 사용 72 | ![separatingChaining](./images/separatingChaining.png) 73 | * Linked List 사용 시 충돌이 발생하면 충돌 발생한 인덱스가 가리키고 있는 Linked List에 노드 추가하여 Value 삽입 74 | * Key에 대한 Value 탐색 시에는 인덱스가 가리키고 있는 Linked List를 선형 검색하여 Value 반환 (삭제도 마찬가지) 75 | * Linked List 구조를 사용하기 때문에 추가 데이터 수 제약이 적은편 76 | 2. Open addressing 77 | * 추가 메모리 공간을 사용하지 않고, HashTable 배열의 빈 공간을 사용하는 방법 78 | * Separating Chaining 방식에 비해 적은 메모리 사용 79 | * 방법은 Linear Probing, Quadratic Probing, Double Hashing 80 | 3. Resizing 81 | * 저장 공간이 일정 수준 채워지면 Separating Chaining의 경우 성능 향을 위해, Open addressing의 경우 배열 크기 확장을 위해 Resizing 82 | * 보통 두배로 확장 83 | * 확장 임계점은 현재 데이터 개수가 Hash Bucket 개수의 75%가 될 때 84 | 85 | * HashTable 장점 86 | * 적은 리소스로 많은 데이터를 효율적으로 관리 가능 87 | * ex. HDD. Cloud에 있는 많은 데이터를 Hash로 매핑하여 작은 크기의 시 메모리로 프로세스 관리 가능 88 | * 배열의 인덱스를 사용하기 때문에 빠른 검색, 삽입, 삭제 (O(1)) 89 | * HashTable의 경우 인덱스는 데이터의 고유 위치이기 때문에 삽입 삭제 시 다른 데이터를 이동할 필요가 없어 삽입, 삭제도 빠른 속도 가능 90 | * Key와 Hash에 연관성이 없어 보안 유리 91 | * 데이터 캐싱에 많이 사용 92 | * get, put 기능에 캐시 로직 추가 시 자주 hit하는 데이터 바로 검색 가능 93 | * 중복 제거 유용 94 | 95 | * HashTable 단점 96 | * 충돌 발생 가능성 97 | * 공간 복잡도 증가 98 | * 순서 무시 99 | * 해시 함수에 의존 100 | 101 | * HashTable vs HashMap 102 | * Key-Value 구조 및 Key에 대한 Hash로 Value 관리하는 것은 동일 103 | * HashTable 104 | * 동기 105 | * Key-Value 값으로 null 미허용 (Key가 hashcode(), equals()를 사용하기 때문) 106 | * 보조 Hash Function과 separating Chaining을 사용해서 비교적 충돌 덜 발생 (Key의 Hash 변형) 107 | * HashMap 108 | * 비동기 (멀티 스레드 환경에서 주의) 109 | * Key-Value 값으로 null 허용 110 | 111 | * HashTable 성능 112 | 113 | | |평균|최악| 114 | |----|----|----| 115 | |탐색|O(1)|O(N)| 116 | |삽입|O(1)|O(N)| 117 | |삭제|O(1)|O(N)| 118 | 119 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 120 | > - [Hash, Hashing, Hash Table(해시, 해싱 해시테이블) 자료구조의 이해](https://velog.io/@cyranocoding/Hash-Hashing-Hash-Table%ED%95%B4%EC%8B%9C-%ED%95%B4%EC%8B%B1-%ED%95%B4%EC%8B%9C%ED%85%8C%EC%9D%B4%EB%B8%94-%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0%EC%9D%98-%EC%9D%B4%ED%95%B4-6ijyonph6o) 121 | > - [[자료구조] Hash/HashTable/HashMap](https://hee96-story.tistory.com/48) 122 | 123 | ### Stack 124 | * 스택(Stack)의 개념 125 | * 한 쪽 끝에서만 자료를 넣고 뺄 수 있는 LIFO(Last In First Out) 형식의 자료 구조 126 | * 스택(Stack)의 연산 127 | * 스택(Stack)는 LIFO(Last In First Out) 를 따른다. 즉, 가장 최근에 스택에 추가한 항목이 가장 먼저 제거될 항목이다. 128 | * pop(): 스택에서 가장 위에 있는 항목을 제거한다. 129 | * push(item): item 하나를 스택의 가장 윗 부분에 추가한다. 130 | * peek(): 스택의 가장 위에 있는 항목을 반환한다. 131 | * isEmpty(): 스택이 비어 있을 때에 true를 반환한다. 132 | * 스택(Stack)의 사용 사례 133 | * 재귀 알고리즘을 사용하는 경우 스택이 유용하다. 134 | * 재귀 알고리즘 135 | * 재귀적으로 함수를 호출해야 하는 경우에 임시 데이터를 스택에 넣어준다. 136 | * 재귀함수를 빠져 나와 퇴각 검색(backtrack)을 할 때는 스택에 넣어 두었던 임시 데이터를 빼 줘야 한다. 137 | * 스택은 이런 일련의 행위를 직관적으로 가능하게 해 준다. 138 | * 또한 스택은 재귀 알고리즘을 반복적 형태(iterative)를 통해서 구현할 수 있게 해준다. 139 | * 웹 브라우저 방문기록 (뒤로가기) 140 | * 실행 취소 (undo) 141 | * 역순 문자열 만들기 142 | * 수식의 괄호 검사 (연산자 우선순위 표현을 위한 괄호 검사) 143 | * Ex) 올바른 괄호 문자열(VPS, Valid Parenthesis String) 판단하기 144 | * 후위 표기법 계산 145 | 146 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 147 | > - [https://gmlwjd9405.github.io/2018/08/03/data-structure-stack.html](https://gmlwjd9405.github.io/2018/08/03/data-structure-stack.html) 148 | 149 | ### Queue 150 | * 큐(Queue)의 개념 151 | * 컴퓨터의 기본적인 자료 구조의 한가지로, 먼저 집어 넣은 데이터가 먼저 나오는 FIFO(First In First Out)구조로 저장하는 형식 152 | * 큐(Queue)의 연산 153 | * 큐(Queue)는 FIFO(First-In-First-Out) 를 따른다. 154 | * add(item): item을 리스트의 끝부분에 추가한다. 155 | * remove(): 리스트의 첫 번째 항목을 제거한다. 156 | * peek(): 큐에서 가장 위에 있는 항목을 반환한다. 157 | * isEmpty(): 큐가 비어 있을 때에 true를 반환한다. 158 | * 큐(Queue)의 사용 사례 159 | * 데이터가 입력된 시간 순서대로 처리해야 할 필요가 있는 상황에 이용한다. 160 | * 너비 우선 탐색(BFS, Breadth-First Search) 구현 161 | * 처리해야 할 노드의 리스트를 저장하는 용도로 큐(Queue)를 사용한다. 162 | * 노드를 하나 처리할 때마다 해당 노드와 인접한 노드들을 큐에 다시 저장한다. 163 | * 노드를 접근한 순서대로 처리할 수 있다. 164 | * 캐시(Cache) 구현 165 | * 우선순위가 같은 작업 예약 (인쇄 대기열) 166 | * 선입선출이 필요한 대기열 (티켓 카운터) 167 | * 콜센터 고객 대기시간 168 | * 프린터의 출력 처리 169 | * 윈도우 시스템의 메시지 처리기 170 | * 프로세스 관리 171 | 172 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 173 | > - [https://gmlwjd9405.github.io/2018/08/02/data-structure-queue.html](https://gmlwjd9405.github.io/2018/08/02/data-structure-queue.html) 174 | 175 | ### Graph 176 | * 그래프(Graph)의 개념 177 | * 단순히 노드(N, node)와 그 노드를 연결하는 간선(E, edge)을 하나로 모아 놓은 자료 구조 178 | * 즉, 연결되어 있는 객체 간의 관계를 표현할 수 있는 자료 구조이다. 179 | * Ex) 지도, 지하철 노선도의 최단 경로, 전기 회로의 소자들, 도로(교차점과 일방 통행길), 선수 과목 등 180 | * 그래프는 여러 개의 고립된 부분 그래프(Isolated Subgraphs)로 구성될 수 있다. 181 | * 그래프(Graph)의 특징 182 | * 그래프는 네트워크 모델 이다. 183 | * 2개 이상의 경로가 가능하다. 184 | * 즉, 노드들 사이에 무방향/방향에서 양방향 경로를 가질 수 있다. 185 | * self-loop 뿐 아니라 loop/circuit 모두 가능하다. 186 | * 루트 노드라는 개념이 없다. 187 | * 부모-자식 관계라는 개념이 없다. 188 | * 순회는 DFS나 BFS로 이루어진다. 189 | * 그래프는 순환(Cyclic) 혹은 비순환(Acyclic)이다. 190 | * 그래프는 크게 방향 그래프와 무방향 그래프가 있다. 191 | * 간선의 유무는 그래프에 따라 다르다. 192 | 193 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 194 | > - [https://gmlwjd9405.github.io/2018/08/13/data-structure-graph.html](https://gmlwjd9405.github.io/2018/08/13/data-structure-graph.html) 195 | 196 | ### Tree 197 | * 트리(Tree)의 개념 198 | * 트리는 노드로 이루어진 자료 구조 199 | 1. 트리는 하나의 루트 노드를 갖는다. 200 | 2. 루트 노드는 0개 이상의 자식 노드를 갖고 있다. 201 | 3. 그 자식 노드 또한 0개 이상의 자식 노드를 갖고 있고, 이는 반복적으로 정의된다. 202 | * 노드(node)들과 노드들을 연결하는 간선(edge)들로 구성되어 있다. 203 | * 트리에는 사이클(cycle)이 존재할 수 없다. 204 | * 노드들은 특정 순서로 나열될 수도 있고 그럴 수 없을 수도 있다. 205 | * 각 노드는 부모 노드로의 연결이 있을 수도 있고 없을 수도 있다. 206 | * 각 노드는 어떤 자료형으로도 표현 가능하다. 207 | * 비선형 자료구조로 계층적 관계를 표현한다. Ex) 디렉터리 구조, 조직도 208 | * 그래프의 한 종류 209 | * 사이클(cycle)이 없는 하나의 연결 그래프(Connected Graph) 210 | * 또는 DAG(Directed Acyclic Graph, 방향성이 있는 비순환 그래프)의 한 종류 이다. 211 | ~~~java 212 | class Node { 213 | public String name; 214 | public Node[] children; 215 | } 216 | ~~~ 217 | * 트리(Tree)의 특징 218 | * 그래프의 한 종류이다. ‘최소 연결 트리’ 라고도 불린다. 219 | * 트리는 계층 모델 이다. 220 | * 트리는 DAG(Directed Acyclic Graphs, 방향성이 있는 비순환 그래프)의 한 종류이다. 221 | * loop나 circuit이 없다. 당연히 self-loop도 없다. 222 | * 즉, 사이클이 없다. 223 | * 노드가 N개인 트리는 항상 N-1개의 간선(edge)을 가진다. 224 | * 즉, 간선은 항상 (정점의 개수 - 1) 만큼을 가진다. 225 | * 루트에서 어떤 노드로 가는 경로는 유일하다. 226 | * 임의의 두 노드 간의 경로도 유일하다. 즉, 두 개의 정점 사이에 반드시 1개의 경로만을 가진다. 227 | * 한 개의 루트 노드만이 존재하며 모든 자식 노드는 한 개의 부모 노드만을 가진다. 228 | * 부모-자식 관계이므로 흐름은 top-bottom 아니면 bottom-top으로 이루어진다. 229 | * 순회는 Pre-order, In-order 아니면 Post-order로 이루어진다. 이 3가지 모두 DFS/BFS 안에 있다. 230 | * 트리는 이진 트리, 이진 탐색 트리, 균형 트리(AVL 트리, red-black 트리), 이진 힙(최대힙, 최소힙) 등이 있다. 231 | 232 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 233 | > - [https://gmlwjd9405.github.io/2018/08/12/data-structure-tree.html](https://gmlwjd9405.github.io/2018/08/12/data-structure-tree.html) 234 | 235 | ### 그래프와 트리의 차이점 236 | 237 | 238 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 239 | 240 | ### Binary Heap 241 | 242 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 243 | > - [https://gmlwjd9405.github.io/2018/05/10/data-structure-heap.html](https://gmlwjd9405.github.io/2018/05/10/data-structure-heap.html) 244 | 245 | ### Red-Black Tree 246 | 247 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 248 | > - [01. Red-Black Tree 개요](https://github.com/namjunemy/TIL/blob/master/Algorithm/red_black_tree_01.md) 249 | > - [02. Red-Black Tree insert fix-up](https://github.com/namjunemy/TIL/blob/master/Algorithm/red_black_tree_02.md) 250 | > - [03. Red-Black Tree delete, fix-up](https://github.com/namjunemy/TIL/blob/master/Algorithm/red_black_tree_03.md) 251 | 252 | ### B+ Tree 253 | 254 | > :arrow_double_up:[Top](#1-data-structure) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#1-data-structure) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 255 | > - []() 256 | 257 | --- 258 | 259 | ## Reference 260 | > - []() 261 | 262 | 263 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 264 | -------------------------------------------------------------------------------- /contents/db.md: -------------------------------------------------------------------------------- 1 | # 4. Database 2 | **:book: Contents** 3 | - [4. Database](#4-database) 4 | - [데이터베이스 풀](#데이터베이스-풀) 5 | - [정규화 1차 2차 3차 BCNF](#정규화-1차-2차-3차-bcnf) 6 | - [트랜잭션이란](#트랜잭션이란) 7 | - [트랜잭션 격리 수준](#트랜잭션-격리-수준) 8 | - [Join](#join) 9 | - [SQL Injection](#sql-injection) 10 | - [Index란](#index란) 11 | - [사용 이유](#사용-이유) 12 | - [동작](#동작) 13 | - [B+tree 알고리즘](#btree-알고리즘) 14 | - [주의할 점](#주의할-점) 15 | - [Statement와 PrepareStatement](#statement와-preparestatement) 16 | - [RDBMS와 NoSQL](#rdbms와-nosql) 17 | - [효과적인 쿼리 저장](#효과적인-쿼리-저장) 18 | - [옵티마이저란](#옵티마이저란) 19 | - [Replication](#replication) 20 | - [파티셔닝](#파티셔닝) 21 | - [샤딩](#샤딩) 22 | - [ORM이란](#orm이란) 23 | - [영속성(Persistence)](#영속성persistence) 24 | - [Persistence layer](#persistence-layer) 25 | - [Persistence framework](#persistence-framework) 26 | - [예시 (JDBC vs JPA)](#예시-jdbc-vs-jpa) 27 | - [장점 - 왜 사용하는가?](#장점---왜-사용하는가) 28 | - [단점](#단점) 29 | - [JDBC](#jdbc) 30 | - [JDBC란?](#jdbc란) 31 | - [JDBC를 이용한 DB접근](#jdbc를-이용한-db접근) 32 | - [1. **JDBC driver 로딩**](#1-jdbc-driver-로딩) 33 | - [2. **Connection 맺기**](#2-connection-맺기) 34 | - [3. **SQL 실행**](#3-sql-실행) 35 | - [(참고) JDBC의 DB접근 플로우](#참고-jdbc의-db접근-플로우) 36 | - [(참고) JDBC 컴포넌트의 상호작용](#참고-jdbc-컴포넌트의-상호작용) 37 | - [Plain JDBC API의 문제점](#plain-jdbc-api의-문제점) 38 | - [JDBC Template](#jdbc-template) 39 | - [:house: Home](#house-home) 40 | 41 | --- 42 | 43 | ### 데이터베이스 풀 44 | - **Connection Pool** 45 | - 클라이언트의 요청에 따라 각 어플리케이션의 스레드에서 데이터베이스에 접근하기 위해서는 Connection이 필요하다. 46 | - Connection pool은 이런 Connection을 여러 개 생성해 두어 저장해 놓은 **공간(캐시)**, 또는 이 공간의 Connection을 필요할 때 꺼내 쓰고 반환하는 **기법**을 말한다. 47 | ![](./images/db-img/db-connection-02.png) 48 | - **DB에 접근하는 단계** 49 | 1. 웹 컨테이너가 실행되면서 DB와 연결된 Connection 객체들을 미리 생성하여 pool에 저장한다. 50 | 2. DB에 요청 시, pool에서 Connection 객체를 가져와 DB에 접근한다. 51 | 3. 처리가 끝나면 다시 pool에 반환한다. 52 | ![](./images/db-img/db-connection-01.jpeg) 53 | - **Connction이 부족하면?** 54 | - 모든 요청이 DB에 접근하고 있고 남은 Conncetion이 없다면, 해당 클라이언트는 대기 상태로 전환시키고 Pool에 Connection이 반환되면 대기 상태에 있는 클라이언트에게 순차적으로 제공된다. 55 | - **왜 사용할까?** 56 | - 매 연결마다 Connection 객체를 생성하고 소멸시키는 비용을 줄일 수 있다. 57 | - 미리 생성된 Connection 객체를 사용하기 때문에, DB 접근 시간이 단축된다. 58 | - DB에 접근하는 Connection의 수를 제한하여, 메모리와 DB에 걸리는 부하를 조정할 수 있다. 59 | - **Thread Pool** 60 | - 비슷한 맥락으로 Thread pool이라는 개념도 있다. 61 | - 이 역시 매 요청마다 요청을 처리할 Thread를 만드는것이 아닌, 미리 생성한 pool 내의 Thread를 소멸시키지 않고 재사용하여 효율적으로 자원을 활용하는 기법. 62 | - **Thread Pool과 Connection pool** 63 | - WAS에서 Thread pool과 Connection pool내의 Thread와 Connection의 수는 직접적으로 메모리와 관련이 있기 때문에, 많이 사용하면 할 수록 메모리를 많이 점유하게 된다. 그렇다고 반대로 메모리를 위해 적게 지정한다면, 서버에서는 많은 요청을 처리하지 못하고 대기 할 수 밖에 없다. 64 | - 보통 WAS의 Thread의 수가 Conncetion의 수보다 많은 것이 좋은데, 그 이유는 모든 요청이 DB에 접근하는 작업이 아니기 때문이다. 65 | 66 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 67 | > - https://delf-lee.github.io/post/connection-pool/ 68 | 69 | ### 정규화 1차 2차 3차 BCNF 70 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 71 | > - []() 72 | 73 | ### 트랜잭션이란 74 | * 트랜잭션(Transaction) 이란 75 | * 데이터베이스의 상태를 변환시키는 하나의 논리적인 작업 단위를 구성하는 연산들의 집합이다. 76 | * 예를들어, A계좌에서 B계좌로 일정 금액을 이체한다고 가정하자. 77 | 1. A계좌의 잔액을 확인한다. 78 | 2. A계좌의 금액에서 이체할 금액을 빼고 다시 저장한다. 79 | 3. B계좌의 잔액을 확인한다. 80 | 4. B계좌의 금액에서 이체할 금액을 더하고 다시 저장한다. 81 | * 이러한 과정들이 모두 합쳐져 계좌이체라는 하나의 작업단위를 구성한다. 82 | * 하나의 트랜잭션은 Commit 되거나 Rollback 된다. 83 | * Commit 연산 84 | * 한개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝나 데이터베이스가 다시 일관된 상태에 있을 때, 이 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다. 85 | * Rollback 연산 86 | * 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되었더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산이다. 87 | * Rollback 시에는 해당 트랜잭션을 재시작하거나 폐기한다. 88 | * 데이터베이스 응용 프로그램은 트랜잭션들의 집합으로 정의 할 수 있다. 89 | * 트랜잭션의 성질(ACID) 90 | * 원자성(Atomicity), All or nothing 91 | * 트랜잭션의 모든 연산들은 정상적으로 수행 완료되거나 아니면 전혀 어떠한 연산도 수행되지 않은 상태를 보장해야 한다. 92 | * 일관성(Consistency) 93 | * 트랜잭션 완료 후에도 데이터베이스가 일관된 상태로 유지되어야 한다. 94 | * 독립성(Isolation) 95 | * 하나의 트랜잭션이 실행하는 도중에 변경한 데이터는 이 트랜잭션이 완료될 때까지 다른 트랜잭션이 참조하지 못한다. 96 | * 지속성(Durability) 97 | * 성공적으로 수행된 트랜잭션은 영원히 반영되어야 한다. 98 | * 트랜잭션의 필요성 99 | * 현금 인출기를 작동하는 도중에 기계오류나 정전 등과 같은 예기치 않은 상황이 발생하여 카드가 나오지 않거나 기계가 멈추는 경우 100 | * 각각 다른 지점의 은행에서 동시에 인출할 때, 하나의 지점이 다른 지점에서 저장한 잔액을 덮어 쓰는 경우 101 | * 위와 같은 상황이 발생되지 않도록 방지하기 위해, 즉, 트랜잭션의 성질인 ACID를 제공받기위해 트랜잭션을 사용한다. 102 | * 트랜잭션의 상태 103 | 104 | * 활동(Active) 105 | * 트랜잭션이 실행 중에 있는 상태, 연산들이 정상적으로 실행 중인 상태 106 | * 장애(Failed) 107 | * 트랜잭션이 실행에 오류가 발생하여 중단된 상태 108 | * 철회(Aborted) 109 | * 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태 110 | * 부분 완료(Partially Committed) 111 | * 트랜잭션이 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태 112 | * 완료(Committed) 113 | * 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태 114 | 115 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 116 | > - [http://limkydev.tistory.com/100](http://limkydev.tistory.com/100) 117 | > - [http://coding-factory.tistory.com/226](http://coding-factory.tistory.com/226) 118 | > - [http://yimoyimo.tk/transaction_DI/](http://yimoyimo.tk/transaction_DI/) 119 | > - [https://d2.naver.com/helloworld/407507](https://d2.naver.com/helloworld/407507) 120 | 121 | ### 트랜잭션 격리 수준 122 | * Isolation Level 이란? 123 | * 트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준 124 | * Isolation Level 의 필요성 125 | * 데이터베이스는 ACID 같이 트랜잭션이 원자적이면서도 독립적인 수행을 하도록 한다. 126 | * 그래서 Locking 이라는 개념이 등장한다. 127 | * 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하게 막는 것 128 | * 하지만 무조건적인 Locking으로 동시에 수행되는 많은 트랜잭션들을 순서대로 처리하는 방식으로 구현되면 DB의 성능은 떨어지게 된다. 129 | * 반대로 응답성을 높이기 위해 Locking 범위를 줄인다면 잘못된 값이 처리 될 여지가 있다. 130 | * 그래서 최대한 효율적인 Locking 방법이 필요하다. 131 | * Isolation Level 의 종류 132 | 1. Read Uncommitted (레벨 0) 133 | * SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리지 않는 Level 134 | * 트랜잭션에 처리중인 혹은 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용한다. 135 | * 따라서, 어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 아직 완료되지 않은(Uncommitted 혹은 Dirty) 트랜잭션이지만 변경된 데이터인 B를 읽을 수 있다. 136 | * 데이터베이스의 일관성을 유지할 수 없다. 137 | 2. Read Committed (레벨 1) 138 | * SELECT 문장이 수행되는 동안 해당 데이터에 Shared Lock이 걸리는 Level 139 | * 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기하게 된다. 140 | * Commit이 이루어진 트랜잭션만 조회할 수 있다. 141 | * 따라서, 어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 해당 데이터에 접근할 수 없다. 142 | * SQL Server가 Default로 사용하는 Isolation Level 143 | 3. Repeatable Read (레벨 2) 144 | * 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 Shared Lock이 걸리는 Level 145 | * 트랜잭션이 범위 내에서 조회한 데이터의 내용이 항상 동일함을 보장한다. 146 | * 따라서, 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정이 불가능하다. 147 | 4. Serializable (레벨 3) 148 | * 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 Shared Lock이 걸리는 Level 149 | * 완벽한 읽기 일관성 모드를 제공한다. 150 | * 따라서, 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능하다. 151 | * Isolation level 조정은 동시성이 증가되는데 반해 데이터 무결성에 문제가 발생할 수 있고, 데이터의 무결성을 유지하는 데 반해 동시성이 떨어질 수 있다. 152 | * 레벨이 높아질수록 비용이 높아진다. 153 | * 낮은 단계의 Isolation Level 이용시 발생하는 현상 154 | 155 | * Dirty Read 156 | * 커밋되지 않은 수정 중인 데이터를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상 157 | * 어떤 트랜잭션에서 아직 실행이 끝난지 않은 다른 트랜잭션에 의한 변경 사항을 보게 되는 되는 경우 158 | * Non-Repeatable Read 159 | * 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션이 값을 수정 또는 삭제함으로써 두 쿼리의 결과가 상이하게 나타나는 비 일관성 현상 160 | * Phantom Read 161 | * 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽을 때, 첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 나타나는 현상 162 | * 이는 트랜잭션 도중 새로운 레코드가 삽입되는 것을 허용하기 때문에 나타난다. 163 | 164 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 165 | > - [http://hundredin.net/2012/07/26/isolation-level/](http://hundredin.net/2012/07/26/isolation-level/) 166 | > - [http://egloos.zum.com/ljlave/v/1530887](http://egloos.zum.com/ljlave/v/1530887) 167 | 168 | ### Join 169 | * 조인이란 170 | * **한 데이터베이스 내의 여러 테이블의 레코드를 조합하여 하나의 열로 표현한 것**이다. 171 | * 따라서 조인은 테이블로서 저장되거나, 그 자체로 이용할 수 있는 결과 셋을 만들어 낸다. 172 | * 조인의 필요성 173 | * 관계형 데이터베이스의 구조적 특징으로 정규화를 수행하면 의미 있는 데이터의 집합으로 테이블이 구성되고, 각 테이블끼리는 관계(Relationship)를 갖게 된다. 174 | * 이와 같은 특징으로 관계형 데이터베이스는 저장 공간의 효율성과 확장성이 향상되게 된다. 175 | * 다른 한편으로는 서로 관계있는 데이터가 여러 테이블로 나뉘어 저장되므로, 각 테이블에 저장된 데이터를 효과적으로 검색하기 위해 조인이 필요하다. 176 | 177 | 178 | 179 | * 조인의 종류 180 | 1. **내부 조인(INNER JOIN)** 181 | * 여러 애플리케이션에서 사용되는 가장 흔한 결합 방식이며, 기본 조인 형식으로 간주된다. 182 | * 내부 조인은 조인 구문에 기반한 2개의 테이블(A, B)의 컬럼 값을 결합함으로써 새로운 결과 테이블을 생성한다. 183 | * **명시적 조인 표현**(explicit)과 **암시적 조인 표현**(implicit) 2개의 다른 조인식 구문이 있다. 184 | * 명시적 조인 표현 185 | * 테이블에 조인을 하라는 것을 지정하기 위해 JOIN 키워드를 사용하며, 그리고 나서 다음의 예제와 같이 ON 키워드를 조인에 대한 구문을 지정하는데 사용한다. 186 | ```sql 187 | SELECT * 188 | FROM employee INNER JOIN department 189 | ON employee.DepartmentID = department.DepartmentID; 190 | ``` 191 | * 암시적 조인 표현 192 | * SELECT 구문의 FROM 절에서 그것들을 분리하는 컴마를 사용해서 단순히 조인을 위한 여러 테이블을 나열하기만 한다. 193 | ```sql 194 | SELECT * 195 | FROM employee, department 196 | WHERE employee.DepartmentID = department.DepartmentID; 197 | ``` 198 | * 결과 199 | 200 | 1. **동등 조인(EQUI JOIN)** 201 | * 비교자 기반의 조인이며, 조인 구문에서 **동등비교만을 사용**한다. 202 | * 다른 비교 연산자(<와 같은)를 사용하는 것은 동등 조인으로서의 조인의 자격을 박탈하는 것이다. 203 | 2. **자연 조인(NATURAL JOIN)** 204 | * 동등 조인의 한 유형으로 조인 구문이 조인된 테이블에서 동일한 컬럼명을 가진 2개의 테이블에서 모든 컬럼들을 비교함으로써, 암시적으로 일어나는 구문이다. 205 | * 결과적으로 나온 조인된 테이블은 동일한 이름을 가진 컬럼의 각 쌍에 대한 단 하나의 컬럼만 포함하고 있다. 206 | * SQL 207 | ```sql 208 | SELECT * FROM employee NATURAL JOIN department; 209 | ``` 210 | * 결과 211 | 212 | 3. **교차 조인(CROSS JOIN)** 213 | * 조인되는 두 테이블에서 곱집합을 반환한다. 214 | * 즉, 두 번째 테이블로부터 각 행과 첫 번째 테이블에서 각 행이 한번씩 결합된 열을 만들 것이다. 215 | * 예를 들어 m행을 가진 테이블과 n행을 가진 테이블이 교차 조인되면 m*n 개의 행을 생성한다 216 | * 명시적 조인 표현 217 | ```sql 218 | SELECT * FROM employee CROSS JOIN department; 219 | ``` 220 | * 암시적 조인 표현 221 | ```sql 222 | SELECT * FROM employee, department; 223 | ``` 224 | * 결과 225 | 226 | 2. **외부 조인(OUTER JOIN)** 227 | * 조인 대상 테이블에서 특정 테이블의 데이터가 모두 필요한 상황에서 외부 조인을 활용하여 효과적으로 결과 집합을 생성할 수 있다. 228 | 1. **왼쪽 외부 조인(LEFT OUTER JOIN)** 229 | * 우측 테이블에 조인할 컬럼의 값이 없는 경우 사용한다. 230 | * 즉, 좌측 테이블의 모든 데이터를 포함하는 결과 집합을 생성한다. 231 | * SQL 232 | ```sql 233 | SELECT * 234 | FROM employee LEFT OUTER JOIN department 235 | ON employee.DepartmentID = department.DepartmentID; 236 | ``` 237 | * 결과 238 | 239 | 2. **오른쪽 외부 조인(RIGHT OUTER JOIN)** 240 | * 좌측 테이블에 조인할 컬럼의 값이 없는 경우 사용한다. 241 | * 즉, 우측 테이블의 모든 데이터를 포함하는 결과 집합을 생성한다. 242 | * SQL 243 | ```sql 244 | SELECT * 245 | FROM employee RIGHT OUTER JOIN department 246 | ON employee.DepartmentID = department.DepartmentID; 247 | ``` 248 | * 결과 249 | 250 | 3. **완전 외부 조인(FULL OUTER JOIN)** 251 | * 양쪽 테이블 모두 OUTER JOIN이 필요할 때 사용한다. 252 | * SQL 253 | ```sql 254 | SELECT * 255 | FROM employee FULL OUTER JOIN department 256 | ON employee.DepartmentID = department.DepartmentID; 257 | ``` 258 | * 결과 259 | 260 | 3. **셀프 조인(SELF JOIN)** 261 | * 한 테이블에서 자기 자신에 조인을 시키는 것이다. 262 | * 조인을 사용할 때 주의사항 263 | * SQL 문장의 의미를 제대로 파악 264 | * SQL을 어떻게 작성하느냐에 따라 성능이 크게 좌우된다. 어떤 질의를 수행할 것인지를 명확하게 정의한 후, 비효율을 제거하여 최적의 SQL을 작성해야 한다. 265 | * 명확한 조인 조건 제공 266 | * 조인 조건을 명확하게 제공하지 않을 경우, 의도치 않게 CROSS JOIN(Cartesian Product)이 수행될 수 있다. 267 | * 조인을 사용할 때 고려사항 268 | * 조인할 대상의 집합을 최소화 269 | * 집합을 최소화할 방법이 있으면, 조건을 먼저 적용하여 관계를 맺을 집합을 최소화한 후, 조인을 맺는 것이 효율적이다. 270 | * 효과적인 인덱스의 활용 271 | * 인덱스를 활용하면, 조인 연산의 비용을 극적으로 낮출 수 있다. 272 | 273 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 274 | > - [https://doooyeon.github.io/2018/11/11/database-join.html](https://doooyeon.github.io/2018/11/11/database-join.html) 275 | 276 | ### SQL Injection 277 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 278 | > - []() 279 | 280 | ### Index란 281 | 인덱스(index)의 원래 뜻은 색인. 데이터베이스에서 조회 및 검색을 더 빠르게 할 수 있는 방법/기술, 혹은 이에 쓰이는 자료구조 자체를 의미하기도 한다. 282 | 283 | #### 사용 이유 284 | `select`문을 사용하여 원하는 조건의 데이터를 검색할 때, 저장된 데이터의 양이 엄청나게 많다면 검색을 위한 순회에 많은 자원과 시간이 소모될 것이다. 이때 도움이 되는게 인덱스이다. 285 | 286 | 자주 조회되는 Column 에 대한 Index Table을 따로 만들어 SELECT 문이 들어왔을 때 Index 테이블에 있는 값들로 결과 값을 조회해 온다. 그래서 Index를 잘 사용한다면 "검색" 연산을 실행했을 때 성능을 올릴 수 있게 된다. 287 | 288 | ![](./images/db-index.png) 289 | 290 | 291 | #### 동작 292 | 293 | - Index Table에서 `where`에 포함된 값을 검색 294 | - 해당 값의 table_id PK를 획득 295 | - 가져온 table_id PK값으로 원본 테이블에서 값을 조회 296 | 297 | DBMS는 인덱스를 다양한 알고리즘으로 관리를 하고 있는데 일반적으로 사용되는 알고리즘은 B+ Tree 알고리즘이다. 298 | 299 | #### B+tree 알고리즘 300 | 301 | ![](./images/db-btree.png) 302 | 303 | - 실제 데이터가 저장된 리프노드(Leaf nodes) 304 | - 리프노드까지의 경로 역할을 하는 논리프노드(Non-leaf nodes) 305 | - 경로의 출발점이 되는 루트 노드(Root node) 306 | 307 | B+tree는 리프노드에 이르기까지에 대한 자식 노드에 포인터가 저장되어 있다. 즉, B+트리의 검색은 루트노드에서 어떤 리프 노드에 이르는 한 개의 경로만 검색하면 되므로 매우 효율적이다. 308 | 309 | ##### B+tree 사용 이유 310 | - **왜 index 생성 시 b-tree를 사용하는지? hash table이 더 효율적이지 않은지?** 311 | - SELECT 질의 조건에는 부등호 연산(<>)도 포함 312 | - hash table은 동등 연산에 특화된 자료구조이기 때문에 부등호 연산 사용 시 문제 발생 313 | 314 | #### 주의할 점 315 | 316 | - 인덱스는 따로 테이블의 형태로 관리가 된다. 자원을 소모한다는 의미. 때문에 무분별한 인덱스의 사용은 성능에 부정적인 영향을 미칠 수 있다. 317 | 318 | - 또한 인덱스는 이진트리를 사용하기 때문에 기본적으로 정렬되어 있다. 이로인해 검색과 조회의 속도를 향상시킬 수 있지만 잦은 데이터의 변경(삽입, 수정 삭제)가 된다면 인덱스 데이블을 변경과 정렬에 드는 오버헤드 때문에 오히려 성능 저하가 일어날 수 있다. 319 | - INSERT : 테이블에는 입력 순서대로 저장되지만, 인덱스 테이블에는 정렬하여 저장하기 때문에 성능 저하 발생 320 | - DELETE : 테이블에서만 삭제되고 인덱스 테이블에는 남아있어 쿼리 수행 속도 저하 321 | - UPDATE : 인덱스에는 UPDATE가 없기 때문에 DELETE, INSERT 두 작업 수행하여 부하 발생 322 | 323 | - 데이터의 중복이 높은 컬럼(카디널리티가 낮은 컬럼)은 인덱스로 만들어도 무용지물 (예: 성별) 324 | - 다중 컬럼 인덱싱할 때 카디널리티가 높은 컬럼->낮은 컬럼 순으로 인덱싱해야 효율적 325 | 326 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 327 | > - [victolee - [DB이론] 인덱스(Index)](https://victorydntmd.tistory.com/319) 328 | > - [Nathan - DB 성능을 위한 Index](https://brunch.co.kr/@skeks463/25) 329 | > - [인덱스 기본 원리](http://wiki.gurubee.net/pages/viewpage.action?pageId=26745270) 330 | 331 | ### Statement와 PrepareStatement 332 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 333 | > - []() 334 | 335 | ### RDBMS와 NoSQL 336 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 337 | > - []() 338 | 339 | ### 효과적인 쿼리 저장 340 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 341 | > - []() 342 | 343 | ### 옵티마이저란 344 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 345 | > - []() 346 | 347 | ### Replication 348 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 349 | > - []() 350 | 351 | ### 파티셔닝 352 | * 배경 353 | * 서비스의 크기가 점점 커지고 DB에 저장하는 데이터의 규모 또한 대용량화 되면서, 기존에 사용하는 DB 시스템의 **용량(storage)의 한계와 성능(performance)의 저하** 를 가져오게 되었다. 354 | * 즉, VLDB(Very Large DBMS)와 같이 하나의 DBMS에 너무 큰 table이 들어가면서 용량과 성능 측면에서 많은 이슈가 발생하게 되었고, 이런 이슈를 해결하기 위한 방법으로 table을 '파티션(partition)'이라는 작은 단위로 나누어 관리하는 **'파티셔닝(Partitioning)'기법** 이 나타나게 되었다. 355 | * 파티셔닝의 개념 356 | * **큰 table이나 index를, 관리하기 쉬운 partition이라는 작은 단위로 물리적으로 분할하는 것을 의미한다.** 357 | * 물리적인 데이터 분할이 있더라도, DB에 접근하는 application의 입장에서는 이를 인식하지 못한다. 358 | * '파티셔닝(Partitioning)'기법을 통해 소프트웨어적으로 데이터베이스를 분산 처리하여 성능이 저하되는 것을 방지하고 관리를 보다 수월하게 할 수 있게 되었다. 359 | * 파티셔닝의 목적 360 | 1. 성능(Performance) 361 | * 특정 DML과 Query의 성능을 향상시킨다. 362 | * 주로 대용량 Data WRITE 환경에서 효율적이다. 363 | * 특히, Full Scan에서 데이터 Access의 범위를 줄여 성능 향상을 가져온다. 364 | * 많은 INSERT가 있는 OLTP 시스템에서 INSERT 작업을 작은 단위인 partition들로 분산시켜 경합을 줄인다. 365 | 2. 가용성(Availability) 366 | * 물리적인 파티셔닝으로 인해 전체 데이터의 훼손 가능성이 줄어들고 데이터 가용성이 향상된다. 367 | * 각 분할 영역(partition별로)을 독립적으로 백업하고 복구할 수 있다. 368 | * table의 partition 단위로 Disk I/O을 분산하여 경합을 줄이기 때문에 UPDATE 성능을 향상시킨다. 369 | 3. 관리용이성(Manageability) 370 | * 큰 table들을 제거하여 관리를 쉽게 해준다. 371 | * 파티셔닝의 장점 372 | * 관리적 측면 : partition 단위 백업, 추가, 삭제, 변경 373 | * 전체 데이터를 손실할 가능성이 줄어들어 데이터 가용성이 향상된다. 374 | * partition별로 백업 및 복구가 가능하다. 375 | * partition 단위로 I/O 분산이 가능하여 UPDATE 성능을 향상시킨다. 376 | * 성능적 측면 : partition 단위 조회 및 DML수행 377 | * 데이터 전체 검색 시 필요한 부분만 탐색해 성능이 증가한다. 378 | * 즉, Full Scan에서 데이터 Access의 범위를 줄여 성능 향상을 가져온다. 379 | * 필요한 데이터만 빠르게 조회할 수 있기 때문에 쿼리 자체가 가볍다. 380 | * 파티셔닝의 단점 381 | * table간 JOIN에 대한 비용이 증가한다. 382 | * table과 index를 별도로 파티셔닝할 수 없다. 383 | * table과 index를 같이 파티셔닝해야 한다. 384 | * 파티셔닝의 종류 385 | 1. 수평(horizontal) 파티셔닝 386 | * **샤딩(Sharding)** 과 동일한 개념 387 | 2. 수직(vertical) 파티셔닝 388 | 389 | * 파티셔닝의 분할 기준 390 | 1. 범위 분할 (range partitioning) 391 | 2. 목록 분할 (list partitioning) 392 | 3. 해시 분할 (hash partitioning) 393 | 4. 합성 분할 (composite partitioning) 394 | 395 | 396 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 397 | > - [https://gmlwjd9405.github.io/2018/09/24/db-partitioning.html](https://gmlwjd9405.github.io/2018/09/24/db-partitioning.html) 398 | > - [https://nesoy.github.io/articles/2018-02/Database-Partitioning](https://nesoy.github.io/articles/2018-02/Database-Partitioning) 399 | 400 | ### 샤딩 401 | 407 | 408 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 409 | > - [http://mongodb.citsoft.net/?page_id=225#comment-91922](http://mongodb.citsoft.net/?page_id=225#comment-91922) 410 | > - [https://d2.naver.com/helloworld/14822](https://d2.naver.com/helloworld/14822) 411 | > - [http://tech.kakao.com/2016/07/01/adt-mysql-shard-rebalancing/](http://tech.kakao.com/2016/07/01/adt-mysql-shard-rebalancing/) 412 | 413 | ### ORM이란 414 | > **O**bject-**R**elational **M**apping 객체-관계 매핑 415 | - 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 것을 말한다. 416 | #### 영속성(Persistence) 417 | - 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 특성. 418 | - 영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 된다. 때문에 파일 시스템, 관계형 테이터베이스 혹은 객체 데이터베이스 등을 활용하여 데이터를 영구하게 저장하여 영속성 부여한다. 419 | #### Persistence layer 420 | 프로그램의 아키텍처에서, 데이터에 영속성을 부여해주는 계층. JDBC를 이용하여 직접 구현할 수 있지만 Persistence framework를 이용한 개발이 많이 이루어진다. 421 | 422 | ![](./images/persistence-layer.png) 423 | 424 | #### [Persistence framework](https://ko.wikipedia.org/wiki/퍼시스턴스_프레임워크) 425 | JDBC 프로그래밍의 복잡함이나 번거로움 없이 간단한 작업만으로 데이터베이스와 연동되는 시스템을 빠르게 개발할 수 있으며 안정적인 구동을 보장한다. 426 | - 종류 427 | - SQL 문장으로 직접 데이터베이스 데이터를 다루는 *SQL 맵퍼* 428 | - Mybatis 등 429 | - **객체를 통해 간접적으로 데이터베이스 데이터를 다루는 *객체 관계 맵퍼(ORM)*** 430 | - Hibernate 등 431 | #### 예시 (JDBC vs JPA) 432 | - JDBC example 433 | ``` java 434 | public String getPersonName(long personId) throws SQLException { 435 | PreparedStatement st = null; 436 | try { 437 | st = connection.prepareStatement ( 438 | "SELECT name FROM people WHERE id = ?"); 439 | st.setLong(1, personId); 440 | ResultSet rs = st.excuteQuery(); 441 | if (ts.next()) { 442 | String result = rs.getString("name"); 443 | assert !rs.next(); 444 | return result; 445 | } else { 446 | return null; 447 | } 448 | } finally { 449 | if (st != null) { 450 | st.close(); 451 | } 452 | } 453 | } 454 | ``` 455 | - JPA example 456 | ``` java 457 | public String getPersonName(long personId) { 458 | Person p = em.find(Person.class, personId); 459 | return p.getName(); 460 | } 461 | ``` 462 | 463 | #### 장점 - 왜 사용하는가? 464 | - **객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 도와준다.** 465 | - 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어든다. 466 | - 각종 객체에 대한 코드를 별도로 작성하기 때문에 코드의 가독성을 올려준다. 467 | - SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적인 접근으로 인해 생산성이 증가한다. 468 | - **재사용 및 유지보수의 편리성이 증가한다.** 469 | - ORM은 독립적으로 작성되어있고, 해당 객체들을 재활용 할 수 있다. 470 | - 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리하다. 471 | - 매핑정보가 명확하여, ERD를 보는 것에 대한 의존도를 낮출 수 있다. 472 | - **DBMS에 대한 종속성이 줄어든다.** 473 | - 대부분 ORM 솔루션은 DB에 종속적이지 않다. 474 | - 종속적이지 않다는것은 구현 방법 뿐만아니라 많은 솔루션에서 자료형 타입까지 유효하다. 475 | - 프로그래머는 Object에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요된다. 476 | - 또한 자바에서 가공할경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능하다. 477 | 478 | #### 단점 479 | - **완벽한 ORM 으로만 서비스를 구현하기가 어렵다.** 480 | - 사용하기는 편하지만 설계는 매우 신중하게 해야한다. 481 | - 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있다. 482 | - 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있다. 483 | - 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있다. 484 | - DBMS의 고유 기능을 이용하기 어렵다. (하지만 이건 단점으로만 볼 수 없다 : 특정 DBMS의 고유기능을 이용하면 이식성이 저하된다.) 485 | - **프로시저가 많은 시스템에선 ORM의 객체 지향적인 장점을 활용하기 어렵다.** 486 | - 이미 프로시저가 많은 시스템에선 다시 객체로 바꿔야하며, 그 과정에서 생산성 저하나 리스크가 많이 발생할 수 있다. 487 | 488 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 489 | > - [[Slide Share] ORM을 활용할 경우의 설계, 개발 과정 - Javajigi](https://www.slideshare.net/javajigi/orm-27141159) 490 | > - [[SlidePlayer] Data Persistence Layer - 思 旁](https://slideplayer.com/slide/11663617/) 491 | > - [ORM - 人CoDOM](http://www.incodom.kr/ORM#h_702209f3f35878a32ee91352ddc6bbe7) 492 | 493 | ### JDBC 494 | #### JDBC란? 495 | > JDBC(Java Database Connectivity)는 DB에 접근할 수 있도록 Java에서 제공하는 API이다. 496 | 497 | - JDBC는 관계형 데이터베이스에 사용되는 SQL문을 실행하기 위해 자바로 작성된 클래스와 인터페이스로 구성되어 있다. 498 | - 특정 데이터베이스나 특정 데이터베이스 메커니즘에 구애 받지않는 독립적인 인터페이스를 통해 다양한 데이터베이스에 접근하는 코드를 구현할 수 있도록 제공하는 자바 클래스의 표준 집합이다. 499 | - JDBC 클래스는 자바 패키지 `java.sql`과 `javax.sql`에 포함되어 있다. 500 | 501 | 데이터베이스 벤더들이 이러한 라이브러리를 각자 만든다면, 자바 프로그래머는 각 벤더가 만든 라이브러리 사용법을 익혀야 할것이다. 502 | 503 | ![](images/jdbc1.png) 504 | 505 | #### JDBC를 이용한 DB접근 506 | - 다음과 같은 순서로 이루어진다. 507 | 1. JDBC driver 로딩 508 | 2. Connection 맺기 509 | 3. SQL 실행 510 | 4. 자원 반환 511 | 512 | #### 1. **JDBC driver 로딩** 513 | - 예) 514 | ``` java 515 | Class.forName("com.mysql.jdbc.Driver"); // mysql 드리이버 로딩 516 | ``` 517 | - Driver란? 518 | - JDBC Driver는 자바 프로그램의 요청을 DBMS가 이해할 수 있는 프로토콜로 변환해주는 클라이언트 사이드 어댑터 519 | #### 2. **Connection 맺기** 520 | - 예) 521 | ``` java 522 | Connection conn = null; 523 | conn = DriverManager.getConnection(URL, USERNAME, PASSWORD); 524 | ``` 525 | - `DriverManager`는 이름 그대로 데이터베이스 벤더들이 JDBC API를 구현한 드라이버를 관리한다. `DriverManager.getConnection()` 메서드는 인자로 들어오는 값에 따라서 특정 데이터베이스 벤더가 구현한 `Connection` 타입의 객체를 반환한다. `Connection` 객체가 생성은 데이터베이스와 연결이 확립되었음을 의미한다. 526 | 527 | #### 3. **SQL 실행** 528 | - 쿼리 준비 529 | ``` java 530 | Statement stmt = conn.createStatement(); 531 | ``` 532 | - 쿼리 실행(쓰기 작업의 경우 - `insert`, `update`, `delete`) 533 | ``` java 534 | rs = stmt.executeQuery(SQL_QUERY_STRING); 535 | ``` 536 | - 쿼리 실행(읽기 작업의 경우 - `select`) 537 | - 결과 값을 받아오는 작업이라면 538 | ``` java 539 | ResultSet rs = psmt.executeQuery(); 540 | ``` 541 | - SQL문이 `select`문이었다면 `ResultSet`을 이용한 처리 542 | - 값 추출 543 | ``` java 544 | while(rs.next()){ 545 | String result1 = resultSet.getString(1) // 컬럼 인덱스 546 | String result2 = resultSet.getString("NAME") // 컬럼명 547 | } 548 | ``` 549 | 이렇게 추출한 값들은 보통 DTO객체로 변환하여 사용한다. 550 | #### 4. 자원 반환 551 | ``` java 552 | rs.close(); // ResultSet를 닫는다. 553 | stmt.close(); // Statement를 닫는다. 554 | conn.close(); // Connection를 닫는다. 555 | ``` 556 | #### (참고) JDBC의 DB접근 플로우 557 | ![](images/jdbc_basic_cycle.png) 558 | 559 | #### (참고) JDBC 컴포넌트의 상호작용 560 | ![](images/jdbc-component-interface-diagram.png) 561 | 562 | #### Plain JDBC API의 문제점 563 | - 쿼리를 실행하기 전과 후에 많은 코드를 작성해야한다. EX) 연결 생성, 명령문, ResultSet 닫기, 연결 등 564 | - 데이터베이스 로직에서 예외 처리 코드를 수행해야 한다. 565 | - 트랜잭션을 처리해야 한다. 566 | - 이러한 모든 코드를 반복하는 것으로, 시간이 낭비된다. 567 | 568 | #### JDBC Template 569 | JDBC Template은 Spring JDBC 접근 방법 중 하나로, 내부적으로 Plain JDBC API를 사용하지만 위와 같은 문제점들을 제거한 형태의 Spring에서 제공하는 class이다. 570 | 571 | ![](images/data-access-layer.png) 572 | - **Spring JDBC가 하는 일** 573 | - 자원의 생성과 반환(Connection, Statement, ResultSet 등) 574 | - Statement 실행 575 | - ResultSet Loop 처리 576 | - Exception 처리와 반환 577 | - Transaction 처리 578 | - **Spring JDBC에서 개발자가 할 일** 579 | - 핵심적으로 해야될 작업만 해주면 나머지는 Framwork가 알아서 처리해준다. 580 | - datasource 설정 581 | - sql문 작성 582 | - 결과 처리 583 | 584 | > :arrow_double_up:[Top](#4-database) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#4-database) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 585 | >- https://gmlwjd9405.github.io/2018/05/15/setting-for-db-programming.html 586 | >- http://www.java-school.net/jdbc/Guide-to-using-JDBC 587 | >- http://ooz.co.kr/272 588 | >- https://ko.wikipedia.org/wiki/JDBC#JDBC_드라이버 589 | >- https://blog.outsider.ne.kr/6 590 | 591 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 592 | -------------------------------------------------------------------------------- /contents/designpattern.md: -------------------------------------------------------------------------------- 1 | # 5. Design Pattern 2 | **:book: Contents** 3 | * [디자인 패턴의 개념과 종류](#디자인-패턴의-개념과-종류) 4 | * [Singleton 패턴](#singleton-패턴) 5 | * [Strategy 패턴](#strategy-패턴) 6 | * [Template Method 패턴](#template-method-패턴) 7 | * [Factory Method 패턴](#factory-method-패턴) 8 | * [MVC1 패턴과 MVC2 패턴](#mvc1-패턴과-mvc2-패턴) 9 | 10 | --- 11 | 12 | ### 디자인 패턴의 개념과 종류 13 | 디자인 패턴이란 14 | * 소프트웨어를 설계할 때 특정 맥락에서 자주 발생하는 고질적인 문제들이 또 발생했을 때 재사용할 할 수있는 훌륭한 해결책 15 | * "바퀴를 다시 발명하지 마라(Don't reinvent the wheel)" 16 | * 이미 만들어져서 잘 되는 것을 처음부터 다시 만들 필요가 없다는 의미이다. 17 | * 패턴이란 18 | * 각기 다른 소프트웨어 모듈이나 기능을 가진 다양한 응용 소프트웨어 시스템들을 개발할 때도 서로 간에 공통되는 설계 문제가 존재하며 이를 처리하는 해결책 사이에도 공통점이 있다. 이러한 유사점을 패턴이라 한다. 19 | * 패턴은 공통의 언어를 만들어주며 팀원 사이의 의사 소통을 원활하게 해주는 아주 중요한 역할을 한다. 20 | 21 | 디자인 패턴의 종류 22 | * GoF 디자인 패턴 23 | * GoF(Gang of Four)라 불리는 사람들 24 | * 에리히 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vissides) 25 | * 소프트웨어 개발 영역에서 디자인 패턴을 구체화하고 체계화한 사람들 26 | * 23가지의 디자인 패턴을 정리하고 각각의 디자인 패턴을 생성(Creational), 구조(Structural), 행위(Behavioral) 3가지로 분류했다. 27 | 28 | GoF 디자인 패턴의 분류 29 | * 30 | 31 | 1. 생성(Creational) 패턴 32 | * 객체 생성에 관련된 패턴 33 | * 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다. 34 | 2. 구조(Structural) 패턴 35 | * 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴 36 | * 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다. 37 | 3. 행위(Behavioral) 38 | * 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴 39 | * 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다. 40 | 41 | > :arrow_double_up:[Top](#5-design-pattern) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#5-design-pattern) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 42 | > - [https://gmlwjd9405.github.io/2018/07/06/design-pattern.html](https://gmlwjd9405.github.io/2018/07/06/design-pattern.html) 43 | 44 | ### Singleton 패턴 45 | * 개념 46 | * 전역 변수를 사용하지 않고 **객체를 하나만 생성** 하도록 하며, 생성된 객체를 **어디에서든지 참조할 수 있도록** 하는 패턴 47 | * '생성(Creational) 패턴'의 하나 48 | * 49 | * 역할이 수행하는 작업 50 | * Singleton 51 | * 하나의 인스턴스만을 생성하는 책임이 있으며 getInstance 메서드를 통해 모든 클라이언트에게 동일한 인스턴스를 반환하는 작업을 수행한다. 52 | * 예시 53 | * 프린터 관리자 만들기 54 | 55 | > :arrow_double_up:[Top](#5-design-pattern) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#5-design-pattern) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 56 | > - [https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html](https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html) 57 | 58 | ### Strategy 패턴 59 | * 개념 60 | * **행위를 클래스로 캡슐화해** 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴 61 | * 같은 문제를 해결하는 여러 알고리즘이 클래스별로 캡슐화되어 있고 이들이 필요할 때 교체할 수 있도록 함으로써 동일한 문제를 다른 알고리즘으로 해결할 수 있게 하는 디자인 패턴 62 | * '행위(Behavioral) 패턴'의 하나 63 | * 즉, **전략을 쉽게 바꿀 수 있도록** 해주는 디자인 패턴이다. 64 | * 전략이란 65 | * 어떤 목적을 달성하기 위해 일을 수행하는 방식, 비즈니스 규칙, 문제를 해결하는 알고리즘 등 66 | * 특히 게임 프로그래밍에서 게임 캐릭터가 자신이 처한 상황에 따라 공격이나 행동하는 방식을 바꾸고 싶을 때 스트래티지 패턴은 매우 유용하다. 67 | * 68 | * 역할이 수행하는 작업 69 | * Strategy 70 | * 인터페이스나 추상 클래스로 외부에서 동일한 방식으로 알고리즘을 호출하는 방법을 명시 71 | * ConcreteStrategy 72 | * 스트래티지 패턴에서 명시한 알고리즘을 실제로 구현한 클래스 73 | * Context 74 | * 스트래티지 패턴을 이용하는 역할을 수행한다. 75 | * 필요에 따라 동적으로 구체적인 전략을 바꿀 수 있도록 setter 메서드('집약 관계')를 제공한다. 76 | * 예시 77 | * 로봇 만들기 78 | 79 | > :arrow_double_up:[Top](#5-design-pattern) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#5-design-pattern) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 80 | > - [https://gmlwjd9405.github.io/2018/07/06/strategy-pattern.html](https://gmlwjd9405.github.io/2018/07/06/strategy-pattern.html) 81 | 82 | ### Template Method 패턴 83 | * 개념 84 | * 어떤 작업을 처리하는 일부분을 **서브 클래스로 캡슐화해** 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴 85 | * 즉, **전체적으로는 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화** 할 때 유용하다. 86 | * 다른 관점에서 보면 동일한 기능을 상위 클래스에서 정의하면서 확장/변화가 필요한 부분만 서브 클래스에서 구현할 수 있도록 한다. 87 | * 예를 들어, 전체적인 알고리즘은 상위 클래스에서 구현하면서 다른 부분은 하위 클래스에서 구현할 수 있도록 함으로써 전체적인 알고리즘 코드를 재사용하는 데 유용하도록 한다. 88 | * '행위(Behavioral) 패턴'의 하나 89 | * 90 | * 역할이 수행하는 작업 91 | * AbstractClass 92 | * 템플릿 메서드를 정의하는 클래스 93 | * 하위 클래스에 공통 알고리즘을 정의하고 하위 클래스에서 구현될 기능을 primitive 메서드 또는 hook 메서드로 정의하는 클래스 94 | * ConcreteClass 95 | * 물려받은 primitive 메서드 또는 hook 메서드를 구현하는 클래스 96 | * 상위 클래스에 구현된 템플릿 메서드의 일반적인 알고리즘에서 하위 클래스에 적합하게 primitive 메서드나 hook 메서드를 오버라이드하는 클래스 97 | * 예시 98 | * 여러 회사의 모터 지원하기 99 | 100 | > :arrow_double_up:[Top](#5-design-pattern) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#5-design-pattern) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 101 | > - [https://gmlwjd9405.github.io/2018/07/13/template-method-pattern.html](https://gmlwjd9405.github.io/2018/07/13/template-method-pattern.html) 102 | 103 | ### Factory Method 패턴 104 | * 개념 105 | * **객체 생성 처리를 서브 클래스로 분리** 해 처리하도록 캡슐화하는 패턴 106 | * 즉, 객체의 생성 코드를 별도의 클래스/메서드로 분리함으로써 객체 생성의 변화에 대비하는 데 유용하다. 107 | * 특정 기능의 구현은 개별 클래스를 통해 제공되는 것이 바람직한 설계다. 108 | * 기능의 변경이나 상황에 따른 기능의 선택은 해당 객체를 생성하는 코드의 변경을 초래한다. 109 | * 상황에 따라 적절한 객체를 생성하는 코드는 자주 중복될 수 있다. 110 | * 객체 생성 방식의 변화는 해당되는 모든 코드 부분을 변경해야 하는 문제가 발생한다. 111 | * [스트래티지 패턴](https://gmlwjd9405.github.io/2018/07/06/strategy-pattern.html), [싱글턴 패턴](https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html), [템플릿 메서드 패턴](https://gmlwjd9405.github.io/2018/07/13/template-method-pattern.html)을 사용한다. 112 | * '생성(Creational) 패턴'의 하나 113 | * 114 | * 역할이 수행하는 작업 115 | * Product 116 | * 팩토리 메서드로 생성될 객체의 공통 인터페이스 117 | * ConcreteProduct 118 | * 구체적으로 객체가 생성되는 클래스 119 | * Creator 120 | * 팩토리 메서드를 갖는 클래스 121 | * ConcreteCreator 122 | * 팩토리 메서드를 구현하는 클래스로 ConcreteProduct 객체를 생성 123 | * 팩토리 메서드 패턴의 개념과 적용 방법 124 | 1. 객체 생성을 전담하는 별도의 **Factory 클래스 이용** 125 | * 스트래티지 패턴과 싱글턴 패턴을 이용한다. 126 | * 해당 Post에서는 이 방법을 기준으로 팩토리 메서드 패턴을 적용한다. 127 | 2. **상속 이용**: 하위 클래스에서 적합한 클래스의 객체를 생성 128 | * 스트래티지 패턴, 싱글턴 패턴과 템플릿 메서드 패턴을 이용한다. 129 | * 해당 Post의 맨 하단에 '다른 방법으로 팩토리 메서드 패턴 적용하기'를 확인한다. 130 | * 예시 131 | * 여러 가지 방식의 엘리베이터 스케줄링 방법 지원하기 132 | 133 | > :arrow_double_up:[Top](#5-design-pattern) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#5-design-pattern) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 134 | > - [https://gmlwjd9405.github.io/2018/08/07/factory-method-pattern.html](https://gmlwjd9405.github.io/2018/08/07/factory-method-pattern.html) 135 | 136 | ### MVC1 패턴과 MVC2 패턴 137 | 138 | > :arrow_double_up:[Top](#5-design-pattern) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#5-design-pattern) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 139 | > - []() 140 | 141 | --- 142 | 143 | ## Reference 144 | > - [JAVA 객체지향 디자인 패턴, 한빛미디어](http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788968480911&orderClick=JAj) 145 | 146 | 147 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 148 | -------------------------------------------------------------------------------- /contents/etc.md: -------------------------------------------------------------------------------- 1 | # 11. ETC 2 | **:book: Contents** 3 | * [TDD란](#tdd란) 4 | * [웹 브라우저에서 서버로 어떤 페이지를 요청하면 일어나는 일련의 과정을 설명](#웹-브라우저에서-서버로-어떤-페이지를-요청하면-일어나는-일련의-과정을-설명) 5 | * [컴파일러와 인터프리터](#컴파일러와-인터프리터) 6 | * [분산락](#분산락) 7 | * [프레임워크와 라이브러리의 차이](#프레임워크와-라이브러리의-차이) 8 | * [64bit CPU와 32bit CPU 차이](#64bit-cpu와-32bit-cpu-차이) 9 | * [CVS, SVN, Git](#cvs-svn-git) 10 | * [Git Branch 종류(5가지)](#git-branch-종류) 11 | * [웹 서버(Web Server)와 웹 어플리케이션 서버(WAS)의 차이](#web-server와-was의-차이) 12 | * [애자일 방법론이란](#애자일-방법론이란) 13 | * [Servlet과 JSP](#servlet과-jsp) 14 | * [Redis와 Memcached의 차이](#redis와-memcached의-차이) 15 | * [Maven과 Gradle의 차이](#maven과-gradle의-차이) 16 | * [Blocking과 Non-Blocking](#blocking과-non-blocking) 17 | * [함수형 프로그래밍이란](#함수형-프로그래밍이란) 18 | * [이벤트 기반 프로그래밍이란](#이벤트-기반-프로그래밍이란) 19 | * [Mock이란](#Mock이란) 20 | 21 | --- 22 | 23 | ### TDD란 24 | * Test Driven Development 25 | * 테스트 주도 개발: 테스트가 개발을 이끌어 나간다. 26 | * 구체적인 행동 레벨에서의 TDD의 개념 27 | * 테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것 28 | * 즉, 만드는 과정에서 우선 테스트를 작성하고 그걸 통과하는 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것이다. 29 | * 추상적인 레벨에서의 TDD의 핵심 개념(중요) 30 | * 결정과 피드백 사이의 갭에 대한 인식, 더 나아가 결정과 피드백 사이의 갭을 조절하기 위한 테크닉이라고도 할 수 있다. 31 | 32 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 33 | > - [https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html](https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html) 34 | 35 | ### 웹 브라우저에서 서버로 어떤 페이지를 요청하면 일어나는 일련의 과정을 설명 36 | * Ex. url에 'www.naver.com' 을 입력했다. 일어나는 현상에 대해 아는대로 설명하라. 37 | * 관련 링크: [http://owlgwang.tistory.com/1](http://owlgwang.tistory.com/1) 38 | 39 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 40 | > - []() 41 | 42 | ### 컴파일러와 인터프리터 43 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 44 | > - []() 45 | 46 | ### 분산락 47 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 48 | > - []() 49 | 50 | ### 프레임워크와 라이브러리의 차이 51 | * 프레임워크(Framework)란 52 | * 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것 53 | * Ex) 자동차의 프레임, 즉 기본적으로 구성하고 있는 뼈대 54 | * 라이브러리(Library)란 55 | * 자주 사용되는 로직을 재사용하기 편리하도록 잘 정리한 일련의 코드들의 집합 56 | * Ex) 자동차의 기능을 하는 부품 57 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 58 | > - [http://moolgogiheart.tistory.com/87](http://moolgogiheart.tistory.com/87) 59 | 60 | ### 64bit CPU와 32bit CPU 차이 61 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 62 | > - []() 63 | 64 | ### CVS, SVN, Git 65 | * 형상관리 툴 66 | * 소스의 변화를 끊임없이 관리하는 툴 67 | * 소스를 버전별로 관리할 수 있고, 실수할 경우 원복 가능하게 하는 툴 68 | 69 | #### CVS 70 | * 개념 71 | * Concurrent Versions System 72 | * GNU 라이센스 73 | * 중앙에 위치한 Repository에 파일을 저장하고, 모든 사용자가 접근 가능하도록 설계 74 | * checkout으로 파일 복사, commit으로 변경사항 저장 75 | * 최종 버전의 소스만 관리 76 | * 먼저 반영한 소스가 먼저 처리되는 시스템 77 | * 장점 78 | * 오랫동안 사용이 되었으며 안정적 79 | * 파일 전체를 저장하지 않고 변경사항만 저장하여 적은 용량 사용 80 | * 단점 81 | * 파일 이동이나 이름 변경은 버전 변경 미발생(파일 지우고 다시 추가) 82 | * 버전 분기가 힘들고, 장기간 분기된 버전 운영에 대해 미설계 83 | * commit 실패 시 롤백 불가능 84 | * 상대적으로 느린 속도 85 | * 혼자 개발할 경우 최종버전만 관리하는 CVS 툴 사용이 편리 86 | 87 | #### SVN 88 | * 개념 89 | * Apache Subversion 90 | * CVS와 높은 호환성을 유지하며 약간의 버그를 수정한 대체 시스템으로 개발 91 | * 중앙 관리 92 | * 최초 1회에 한해 파일 원본 저장, 이후에는 원본과 차이점을 저장 93 | * 버전 분기가 쉽고, 대규모의 분기된 프로젝트에 도움 94 | * 장점 95 | * 원자적 commit으로 다른 사용자의 commit과 엉키지 않으며 commit 실패 시 롤백 지원 96 | * 원자적 commit : 파일 단위가 아닌 change set이 commit 단위 97 | * 효율적인 버전 분기, 언제든지 원하는 버전으로 복구 가능 98 | * 이진파일도 효율적으로 저장 가능 99 | * 단점 100 | * 파일과 디렉토리 변경 관련 버그 101 | * 불충분한 저장소 관리 명령어 102 | * CVS에 비해 상대적으로 불안정 103 | * **Local Repository가 없기** 때문에 자신만의 version history 관리 불가능 104 | * commit에 실수가 있을 시 다른 개발자에게 바로 영향 가능성 105 | 106 | #### Git 107 | * 개념 108 | * CVS를 개선하고, 보다 빠른 분산 버전 제어 시스템 109 | * **서버 저장소와 개발자 저장소가 독립적** 110 | * 사용자 기록 탐색 가능 111 | * 장점 112 | * 빠른 속도 113 | * 분기 버전의 효율적인 운영 114 | * 오프라인에서도 전체 이력 이용 가능 115 | * 분산된 P2P 모델 116 | * commit에 실수가 있어도 서버에 바로 영향 없음 117 | * 단점 118 | * SVN보다 많은 기능을 지원하는 만큼 높은 진입장벽 119 | * 개인 개발자에게 부적절 120 | * 팀 개발을 위한 분산 환경 코딩에 최적화 121 | 122 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 123 | > - [[IT/트랜드] [금융IT]형상관리 툴 CVS, SVN, 그리고 Git비교](https://daitso.kbhub.co.kr/50240/) 124 | > - [[웹개발 기초] 형상관리툴이란? (SVN GIT 간단비교)](https://goddaehee.tistory.com/158) 125 | > - [형상관리툴 특징 (Perforce, Git, SVN, CVS)](https://haayany.tistory.com/entry/%ED%98%95%EC%83%81%EA%B4%80%EB%A6%AC%ED%88%B4-%ED%8A%B9%EC%A7%95-Perforce-Git-SVN-CVS) 126 | > - [형상 관리 툴 비교 Git, SVN, CVS](https://digital-play.tistory.com/60) 127 | 128 | ### Git Branch 종류 129 | 1. Master Branch 130 | * **제품으로 출시될 수 있는 브랜치** 131 | * 배포(Release) 이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다. 132 | 2. Develop Branch 133 | * **다음 출시 버전을 개발하는 브랜치** 134 | * 기능 개발을 위한 브랜치들을 병합하기 위해 사용. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)한다. 135 | * 평소에는 이 브랜치를 기반으로 개발을 진행한다. 136 | 3. Feature branch 137 | * **기능을 개발하는 브랜치** 138 | * feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기한다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 자신의 로컬 저장소에서 관리한다. 139 | * 개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다. 140 | 4. Release Branch 141 | * **이번 출시 버전을 준비하는 브랜치** 142 | * 배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 아주 좋다. 143 | * 예를 들어, ‘이번 주에 버전 1.3 배포를 목표로 한다!’라고 팀 구성원들과 쉽게 소통하고 합의할 수 있다는 말이다. 144 | 5. Hotfix Branch 145 | * **출시 버전에서 발생한 버그를 수정 하는 브랜치** 146 | * 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘master’ 브랜치에서 분기하는 브랜치이다. ‘develop’ 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 ‘master’ 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 ‘master’브랜치에 병합하여 이를 배포해야 하는 것이다. 147 | 148 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 149 | > - [https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html](https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html) 150 | 151 | 152 | ### Web Server와 WAS의 차이 153 | * Web Server 154 | * Web Server의 개념 155 | * 소프트웨어와 하드웨어로 구분된다. 156 | * 1) 하드웨어 157 | * Web 서버가 설치되어 있는 컴퓨터 158 | * 2) 소프트웨어 159 | * 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 **정적인 컨텐츠(.html .jpeg .css 등)**를 제공하는 컴퓨터 프로그램 160 | * Web Server의 기능 161 | * **HTTP 프로토콜을 기반으로 하여 웹 브라우저의 요청을 서비스 하는 기능**을 담당한다. 162 | * 요청에 따라 아래의 두 가지 기능 중 적절하게 선택하여 수행한다. 163 | * 기능 1) 164 | * 정적인 컨텐츠 제공 165 | * WAS를 거치지 않고 바로 자원을 제공한다. 166 | * 기능 2) 167 | * 동적인 컨텐츠 제공을 위한 요청 전달 168 | * 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다. 169 | * Web Server의 예 170 | * Ex) Apache Server, Nginx, IIS(Windows 전용 Web 서버) 등 171 | * WAS(Web Application Server) 172 | * WAS의 개념 173 | * DB 조회나 다양한 로직 처리를 요구하는 **동적인 컨텐츠**를 제공하기 위해 만들어진 Application Server 174 | * HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다. 175 | * **"웹 컨테이너(Web Container)" 혹은 "서블릿 컨테이너(Servlet Container)"**라고도 불린다. 176 | * Container란 JSP, Servlet을 실행시킬 수 있는 소프트웨어를 말한다. 177 | * 즉, WAS는 JSP, Servlet 구동 환경을 제공한다. 178 | * WAS의 기능 179 | * **WAS = Web Server + Web Container** 180 | * Web Server 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다. 181 | * 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다. 182 | * 주로 DB 서버와 같이 수행된다. 183 | * WAS의 예 184 | * Ex) Tomcat, JBoss, Jeus, Web Sphere 등 185 | 186 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 187 | > - [https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html](https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html) 188 | 189 | ### 애자일 방법론이란 190 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 191 | > - [https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html](https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html) 192 | 193 | ### Servlet과 JSP 194 | * 기능의 차이는 없고 역할의 차이만 있다. (하는 일은 동일) 195 | * Servlet이란 196 | * 웹 기반의 요청에 대한 동적인 처리가 가능한 Server Side에서 돌아가는 Java Program 197 | * ***Java 코드*** 안에 HTML 코드 (하나의 클래스) 198 | * 웹 개발을 위해 만든 표준 199 | * **data processing(Controller)** 에 좋다. 200 | * 즉 DB와의 통신, Business Logic 호출, 데이터를 읽고 확인하는 작업 등에 유용하다. 201 | * Servlet이 수정된 경우 Java 코드를 컴파일(.class 파일 생성)한 후 동적인 페이지를 처리하기 때문에 전체 코드를 업데이트하고 다시 컴파일한 후 재배포하는 작업이 필요하다. **(개발 생산성 저하)** 202 | * 구체적인 내용은 [https://gmlwjd9405.github.io/2018/10/28/servlet.html](https://gmlwjd9405.github.io/2018/10/28/servlet.html) 참고 203 | * JSP란 204 | * Java 언어를 기반으로 하는 Server Side 스크립트 언어 205 | * ***HTML 코드*** 안에 Java 코드 206 | * Servlet를 보완하고 기술을 확장한 스크립트 방식 표준 207 | * Servlet의 모든 기능 + 추가적인 기능 208 | * ![](/images/web/jsp-definition.png) 209 | * **presentation(View)** 에 좋다. 210 | * 즉 요청 결과를 나타내는 HTML 작성하는데 유용하다. 211 | * JSP가 수정된 경우 재배포할 필요가 없이 WAS가 알아서 처리한다. **(쉬운 배포)** 212 | * 구체적인 내용은 [https://gmlwjd9405.github.io/2018/11/03/jsp.html](https://gmlwjd9405.github.io/2018/11/03/jsp.html) 참고 213 | 214 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 215 | > - [https://gmlwjd9405.github.io/2018/11/04/servlet-vs-jsp.html](https://gmlwjd9405.github.io/2018/11/04/servlet-vs-jsp.html) 216 | 217 | ### Redis와 Memcached의 차이 218 | 219 | #### Redis and Memcached 220 | * 분산 메모리 캐싱 시스템(인메모리 데이터 저장소) 221 | * 데이터를 Key-Value 형태로 메모리에 저장하는 방식(NoSql) 222 | * 데이터베이스 부하를 줄여 동적 웹 애플리케이션의 속도 개선을 위해 사용 223 | * 데이터 파티셔닝을 통해 많은 데이터를 효과적으로 처리 가능 224 | 225 | ##### Memcached 메모리 구조 226 | 227 | ![memcached](./images/memcached-usage.png) 228 | * Memcached 미사용 시(위) 229 | * 각 웹 서버는 할당된 메모리만큼만 캐시 사용 가능 230 | * 웹 서버가 사용 가능한 전체 용량의 일부분만 사용하기 때문에 낭비 발생 231 | * Memcached 사용 시(아래) 232 | * 각 웹 서버는 메모리 공간이 논리적으로 통합된 가상 풀을 바라보고 있기 때문에 전체 메모리 크기만큼의 캐시 사용 가능 233 | * 효율성 있는 메모리 운용 가능 234 | * 특정 항목이 주어졌을 때 전체 웹 클러스터에서 항상 동일한 위치에 저장 및 검색 가능 235 | * 서버 증설 시, 정기적으로 접근되는 데이터의 캐싱을 통해 DB나 API 호출 횟수 감소 236 | 237 | #### Redis vs Memcached 238 | 239 | | |**Redis**|**Memcached**| 240 | |----|----|----| 241 | |데이터 타입|String, Set, Sorted Set, Hash, List|String| 242 | |데이터 저장|Memory, Disk|Memory| 243 | |메모리 재사용|X
명시적으로만 데이터 제거 가능|메모리 부족 시 LRU 알고리즘으로 데이터 삭제 후 재사용| 244 | |스레드|단일 스레드|멀티 스레드| 245 | |캐싱 용량|Key, Value 모두 512MB|Key 250byte, Value 1MB| 246 | 247 | ##### Redis만의 장점 248 | * 다양한 자료구조 지원 249 | * 데이터 복구 가능 및 데이터 영속성 250 | * Snapshots 방식 : 특정 시점에 데이터를 디스크에 저장하여 파일 보관 251 | * AOF 방식 : 이벤트를 로그에 남겨서 로그 기반 복구 252 | * 마스터 슬레이브 구조로 여러개의 복제본 생성 가능 253 | * 다양한 데이터 Eviction 정책 지원 254 | * Eviction : 캐시가 데이터 공간 확보를 위해 사용하지 않는 데이터를 지우는 것 255 | * PUB/SUB 기능 제공 256 | * 게시자/구독자의 메시지 패러다임을 구현 257 | * 게시된 메시지는 구독자가 누구인지는 모르고 채널로 구분 258 | * 구독자는 하나 이상의 채널에 관심을 갖고(구독), 게시자는 누구인지 알 필요 없이 관심있는 메시지만 수신 259 | * 트랜잭션 지원 260 | * 위치기반 데이터 타입 지원 261 | 262 | ##### Redis 단점 263 | * Copy-on-Write 방식으로 사용할 메모리의 두 배 필요 264 | * 리눅스는 부모 프로세스와 자식 프로세스 간 메모리를 공유하는데, 공유 할 수 없는 상황에 대비해 복사한 다음 수정하는 특징 265 | * 실제 사용하는 메모리보다 임시로 데이터를 복사하고 수정할 수 있는 더 많은 메모리 필요 266 | * Copy-on-Write는 Redis의 수정 관련 명령 실행 시 발생 267 | * [참고](https://real-dongsoo7.tistory.com/114) 268 | * 메모리 파편화 발생 가능 269 | 270 | ##### Memcached만의 장점 271 | * 멀티스레드 아키텍처 지원 272 | * Redis에 비해 적은 메모리 요구 273 | * 정적인 데이터 캐싱 시 유리 274 | 275 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 276 | > - [Memcached, Redis : 메모리 캐시](https://ojava.tistory.com/70) 277 | > - [About Memcached](https://memcached.org/about) 278 | > - [[Spring] Spring은 왜 memcached 대신 Redis를 선택했을까?](https://deveric.tistory.com/65) 279 | > - [[Cache] Redis vs. Memcached](https://medium.com/@chrisjune_13837/redis-vs-memcached-10e796ddd717) 280 | > - [[Redis] Pub/Sub 설명](https://realmojo.tistory.com/170) 281 | > - [[Cache]Redis vs Memcached](https://americanopeople.tistory.com/148) 282 | > - [In memory dictionary Redis 소개](https://bcho.tistory.com/654) 283 | 284 | ### Maven과 Gradle의 차이 285 | * Maven 286 | * Gradle 287 | 288 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 289 | > - [https://ojava.tistory.com/70](https://ojava.tistory.com/70) 290 | 291 | ### Blocking과 Non-Blocking 292 | * 직접 제어할 수 없는 대상을 처리하는 방법에 따라 블록/논블록 293 | * ex. IO, 멀티쓰레드 동기화 294 | * Blocking 295 | * 함수 호출 시 호출된 함수에게 제어권이 넘어가고, 해당 함수가 끝날 때까지 호출한 함수는 대기 296 | * Non-Blocking 297 | * 호출된 함수가 바로 return해서 호출한 함수에게 제어권을 돌려주어 다른 작업 진행 가능 298 | 299 | ### Blocking, Non-Blocking vs Synchronous, Asynchronous 300 | ![blocking](./images/blocking.png) 301 | * 두 그룹의 차이점은 관심사 302 | * Blocking/Non-Blocking 303 | * 호출된 함수의 return 여부에 관심 304 | * 호출된 함수의 제어권 소유 여부로 구분 305 | * Synchronous/Asynchronous 306 | * 호출된 함수의 작업 완료 여부를 신경쓰는 주체에 관심 307 | * Asynchronous 308 | * 호출된 함수에 callback을 전달하여 해당 함수가 작업 완료 시 callback을 실행 309 | * 이 때, 호출한 함수는 호출된 함수의 작업 완료 여부를 신경쓰지 않아도 됨 310 | * Synchronous 311 | * 호출한 함수가 호출된 함수의 return을 기다리거나 또는 바로 return 받더라도 작업 완료 여부를 신경쓰는 것 312 | 313 | ### Non-Blocking, Synchronous 314 | ![nonb-sync](./images/non-sync.png) 315 | * 호출된 함수는 바로 return, 호출한 함수는 호출된 함수의 작업 완료 여부 확인 316 | * 호출한 함수 본인은 함수 호출 후 바로 다른 작업 수행이 가능하지만 호출된 함수의 완료 여부를 계속 확인하는 동작 317 | 318 | ### Blocking, Asynchronous 319 | ![b-async](./images/b-async.png) 320 | * 호출된 함수는 바로 return하지 않고, 호출한 함수는 호출된 함수의 작업 완료 여부 미확인 321 | * Blocking, Synchronous 방식과 큰 차이 없음 322 | * [참고] Non-Blocking, Asynchronous 방식을 사용하려던 의도와 다르게 Blocking, Asynchronous 되어버리는 경우가 존재 323 | * ex. Node.js와 MySQL 조합 324 | * Node.js가 Async 동작을 해도, DB 호출 시 MySQL 드라이버가 Blocking 방식 325 | * Non-Blocking, Asynchronous 방식 사용 중 하나라도 Blocking 동작을 한다면 의도치 않게 Blocking, Asynchronous 동작 326 | 327 | > :arrow_double_up:[Top](#11-etc) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#11-etc) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 328 | > - [Blocking-NonBlocking-Synchronous-Asynchronous](http://homoefficio.github.io/2017/02/19/Blocking-NonBlocking-Synchronous-Asynchronous/) 329 | > - [Sync VS Async, Blocking VS Non-Blocking](https://velog.io/@codemcd/Sync-VS-Async-Blocking-VS-Non-Blocking-sak6d01fhx) 330 | 331 | ### 함수형 프로그래밍이란 332 | 333 | #### 프로그래밍 패러다임 334 | * 명령형 프로그래밍 335 | * 애플리케이션의 상태와 상태를 변경시키는 구문의 관점에서 연산을 설명하는 방식 336 | * 어떻게 할 것인지 표현 337 | * 절차지향 프로그래밍 338 | * 객체지향 프로그래밍 339 | * 선언형 프로그래밍 340 | * 무엇을 할 것인지 표현 341 | * **함수형 프로그래밍** 342 | 343 | #### 함수형 패러다임의 등장 계기 344 | * 하드웨어의 발전과 함께 소프트웨어 패러다임은 TEXT기반의 절차적 프로그래밍에서 GUI기반의 객체지향 프로그래밍으로 변화하였고, 이제 멀티코어를 배경으로 하는 함수형 프로그래밍으로 변화 345 | * **대용량의 데이터를 빠르고 효율적으로 처리하기 위해서 멀티코어를 활용하는 병렬처리 프로그래밍 도입이 필요** 346 | * 안정적으로 다루기 위해서는 함수형 프로그램이 필연적인 선택 347 | * 또한, **프로그램을 보다 단순하게 하려는 요구사항**에 의해 등장 348 | 349 | #### 함수형 프로그래밍 개념 350 | * 선언형 프로그래밍 351 | * 함수형 프로그래밍은 계산을 수학적 함수의 조합으로 생각하는 방식 352 | * 함수를 1급 객체로 사용(고차 함수) 353 | * 1급 객체가 될 수 있는 조건 354 | * 변수나 데이터 구조 안에 담을 수 있는 객체 355 | * 함수의 파라미터로 전달 가능 356 | * 반환값으로 사용 가능 357 | * 할당에 사용된 이름과 관계없이 고유한 구별 가능 358 | * 동적으로 프로퍼티 할당 가능 359 | * 애플리케이션의 상태는 순수 함수를 통해 전달 360 | * 공유 상태와 side effect 대신 순수 함수를 사용 361 | * 순수 함수 : 같은 입력이 주어지면 항상 같은 출력을 반환하는 함수 362 | * 명령형 흐름 제어보다 합성 함수를 사용 363 | * 합성 함수 : 새로운 함수를 만들거나 계산하기 위해 둘 이상의 함수를 조합 364 | * ex. 메소드 체이닝 365 | * 불변성 366 | * 함수형 프로그래밍의 핵심 개념 367 | * 함수를 1급 객체로 사용하며 함수를 조합하고, 공유 상태와 변경 가능한 데이터 및 사이드 이펙트를 피해 소프트웨어를 만드는 프로세스 368 | 369 | #### 함수형 프로그래밍 특징 370 | * 변경 가능한 상태를 불변 상태로 만들어 side effect 방지 가능 371 | * 고차함수를 통한 재사용성 증가 372 | * 코드를 간결하게 하고 가독성을 높여 구현할 로직에 집중 373 | * 동시성 작업을 보다 쉽고 안전하게 구현 가능 374 | 375 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#7-java) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 376 | > - [함수형 프로그래밍 요약](https://velog.io/@kyusung/%ED%95%A8%EC%88%98%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%9A%94%EC%95%BD) 377 | > - [번역 - 함수형 프로그래밍이란 무엇인가?](https://sungjk.github.io/2017/07/17/fp.html) 378 | > - [람다, 람다, 람다(Lambda, Lambda, Lambda) - 1](http://blog.naver.com/tmondev/220412722908) 379 | 380 | 381 | ### 이벤트 기반 프로그래밍이란 382 | #### 개념 383 | - 프로그램의 제어 흐름이 이벤트의 발생에 의해 결정되는 컴퓨터 프로그래밍 패러다임 384 | - 프로그램이 다양한 형태의 사용자 이벤트(클릭, 키 입력)에 응답 385 | - 이벤트 리스너가 대기하고, 이벤트가 발생(요청)하면 해당 이벤트와 상황에 등록된 이벤트 핸들러(콜백 함수)를 실행하여 관련 데이터를 전달해 응답 386 | 387 | #### 특징 388 | - 마이크로 서비스 사이의 결합도를 낮추고 비동기적인 문제 처리 시 유용 389 | - 이벤트 소스(마우스, 키보드 등)는 본인이 발생시킬 수 있는 이벤트를 보유 390 | - 이벤트 소스를 먼저 정의하고, 소스가 일으킬 수 있는 이벤트를 정의하는 방식으로 구현 391 | 392 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#7-java) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 393 | > - [[프로그래밍 패러다임]이벤트 기반 프로그래밍(Event-based programming)](https://kamang-it.tistory.com/entry/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%ED%8C%A8%EB%9F%AC%EB%8B%A4%EC%9E%84%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EA%B8%B0%EB%B0%98-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8DEvent-based-programming) 394 | 395 | ### Mock이란 396 | 397 | #### Mock 개념 398 | - 실제 객체를 만들어 사용하기에는 비용이 크고, 객체간 의존성이 높아 구현하기 힘들 경우 만드는 **가짜 객체** 399 | 400 | #### Mock 사용 예시 401 | - 테스트 작성을 위한 환경 구축 402 | - 테스트가 특정 경우나 순간에 의존적인 경우 403 | - 테스트 시간이 오래 걸리는 경우 404 | - 개인 PC나 서버의 성능 문제로 동작이 오래 걸릴 수 있는 경우 405 | 406 | #### Mock 관련 용어 407 | 1. 테스트 더블(Test double) 408 | - 테스트를 진행하기 어려운 경우, 대신 테스트를 진행할 수 있도록 만들어주는 객체 409 | - Mock 객체와 비슷하지만 테스트 더블이 Mock 객체보다 상위 개념 410 | 411 | 2. 더미객체(Dummy object) 412 | - 단순히 인스턴스화 될 수 있는 수준으로만 객체 구현 413 | - 인스턴스화 된 객체 자체를 필요로하고, 해당 객체의 기능까지는 필요하지 않을 때 사용 414 | 415 | 3. 테스트 스텁(Test stub) 416 | - 더미 객체가 실제로 동작하는 것처럼 보이게 만들어놓은 객체 417 | - 객체의 특정 상태를 가정해서 작성하고 특정 **값을 반환하거나 메시지 출력** 418 | - 가정한 값을 하드코딩으로 작성하기 때문에 값의 변경은 테스트 불가능 419 | - 어떤 행위가 호출됐을 때 특정 값으로 반환해주는 형태 420 | - **객체의 상태를 검증** 421 | 422 | 4. 페이크 객체(Fake object) 423 | - 실제 로직이 구현된 것처럼 보이는 객체 424 | - 실제로 DB에 접속해서 비교할 때와 동일한 결과가 보이도록 객체 내부에 구현 가능 425 | - 보통 List나 Map을 이용 426 | - 테스트케이스 작성 시 다른 객체들과 의존성을 제거하기 위해 사용 427 | - 페이크 객체 만들 때 비용이 많이 발생할 경우 적절한 수준으로만 구현하거나 Mock 프레임워크 사용 또는 실제 객체를 가져와 테스트 428 | 429 | 5. 테스트 스파이(Test spy) 430 | - 테스트에 사용하는 객체와 메소드의 사용 여부 및 정상 호출 여부를 기록하고 요청 시 알림 431 | - 행위 기반 테스트가 필요한 경우 사용(특정 메소드 호출 시 또다른 메소드 실행하는 등) 432 | 433 | 6. Mock 객체 434 | - **행위를 검증**하기 위해 사용하는 객체 435 | ```JAVA 436 | public class MessageSender { 437 | private CellphoneService service; 438 | 439 | public MessageSender(CellphoneService service) { 440 | this.service = service; 441 | } 442 | 443 | public void send(String msg) { 444 | service.sendMMS(msg); 445 | } 446 | } 447 | ``` 448 | - ```CellphoneService```와 ```MessageSender``` 객체가 있을 때, 실제로 문자를 보내는 것은 ```CellphoneService```의 책임이며, ```MessageSender```는 ```CellphoneService```의 ```sendMMS()``` 메소드를 호출하는 역할 449 | - 호출 여부를 테스트하는 것이 **행위를 검증**하는 것 450 | - stub과의 차이 451 | - stub은 객체의 반환값이나 상태값을 검증하는 것 452 | - mock은 메소드 호출 여부, 메소드의 동작 여부를 검증 453 | - ```MessageSender``` 테스트 시, ```CellphoneService```의 **가짜 객체**를 만들어 검증할 수 있으며 이 가짜 객체가 **Mock 객체** 454 | - Mock 객체 수동 생성 455 | ```JAVA 456 | public class CellphoneServiceMock extends CellphoneService { 457 | private boolean isSendMMSCalled = false; 458 | private String sendMsg = ""; 459 | 460 | @Override 461 | public void sendMMS(String msg) { 462 | // 실제 동작하는 부모 객체 호출 대신 테스트 동작 처리 호출 여부만 확인하도록 구현 463 | // super.sendMMS(msg); 464 | 465 | isSendMMSCalled = true; 466 | sendMsg = msg; 467 | } 468 | 469 | public boolean isSendMMSCalled() { 470 | return isSendMMSCalled; 471 | } 472 | 473 | public Stirng getSendMsg() { 474 | return sendMsg; 475 | } 476 | } 477 | ``` 478 | ```JAVA 479 | // Mock 객체를 사용한 테스트 코드 480 | public class MessageSenderTest { 481 | @Test 482 | public void testSend() throws Exception { 483 | // Given 484 | final String message = "테스트 문자 메시지입니다."; 485 | CellphoneServiceMock mock = new CellphoneServiceMock(); 486 | MessageSender sender = new MessageSender(mock); 487 | 488 | // When 489 | sender.send(message); 490 | 491 | // Then 492 | assertTrue(mock.isSendMMSCalled()); 493 | assertEqual(message, mock.getSendMsg()); 494 | } 495 | } 496 | ``` 497 | - 프레임워크를 사용한 Mock 객체 생성 498 | - 대표적으로 Mockito가 지원하는 mock을 사용해 별도의 Mock 객체(CellphoneServiceMock)를 만들지 않고 Mock 객체 생성 가능 499 | ```JAVA 500 | public class MessageSenderTest { 501 | @Test 502 | public void testSend() throws Exception { 503 | // Given 504 | final String message = "테스트 문자 메시지"; 505 | CellphoneService mock = mock(CellphoneService.class); 506 | MessageSender sender = new MessageSender(mock); 507 | 508 | // When 509 | sender.send(message); 510 | 511 | // Then - CellphoneService의 sendMMS() 호출 여부 검증 512 | verify(mock).sendMMS(message); 513 | } 514 | } 515 | ``` 516 | - 행위 기반 테스트는 작성하기 어려운 부분이 많기 때문에 상태 기반 테스트가 가능하다면 생략 가능 517 | 518 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#7-java) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 519 | > - [[Mockito] Mock 개념(Mock Object)](https://www.crocus.co.kr/1555) 520 | > - [Mock Object란 무엇인가?](https://medium.com/@SlackBeck/mock-object%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-85159754b2ac) 521 | 522 | 523 | --- 524 | 525 | ## Reference 526 | > -[]() 527 | 528 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 529 | -------------------------------------------------------------------------------- /contents/images/3-way-handshaking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/3-way-handshaking.png -------------------------------------------------------------------------------- /contents/images/4-way-handshaking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/4-way-handshaking.png -------------------------------------------------------------------------------- /contents/images/BigO-complexity-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/BigO-complexity-chart.png -------------------------------------------------------------------------------- /contents/images/JVMHeap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/JVMHeap.png -------------------------------------------------------------------------------- /contents/images/access-controller.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/access-controller.png -------------------------------------------------------------------------------- /contents/images/b-async.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/b-async.png -------------------------------------------------------------------------------- /contents/images/bfs-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/bfs-example.png -------------------------------------------------------------------------------- /contents/images/bfs-vs-dfs.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/bfs-vs-dfs.gif -------------------------------------------------------------------------------- /contents/images/blocking.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/blocking.png -------------------------------------------------------------------------------- /contents/images/cookie-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/cookie-process.png -------------------------------------------------------------------------------- /contents/images/cross-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/cross-join.png -------------------------------------------------------------------------------- /contents/images/data-access-layer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/data-access-layer.png -------------------------------------------------------------------------------- /contents/images/data-encapsulation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/data-encapsulation.png -------------------------------------------------------------------------------- /contents/images/db-btree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/db-btree.png -------------------------------------------------------------------------------- /contents/images/db-img/db-connection-01.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/db-img/db-connection-01.jpeg -------------------------------------------------------------------------------- /contents/images/db-img/db-connection-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/db-img/db-connection-02.png -------------------------------------------------------------------------------- /contents/images/db-index.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/db-index.png -------------------------------------------------------------------------------- /contents/images/dfs-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/dfs-example.png -------------------------------------------------------------------------------- /contents/images/equals-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/equals-example.png -------------------------------------------------------------------------------- /contents/images/factory-method-pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/factory-method-pattern.png -------------------------------------------------------------------------------- /contents/images/filterInterceptor.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/filterInterceptor.jpg -------------------------------------------------------------------------------- /contents/images/full-outer-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/full-outer-join.png -------------------------------------------------------------------------------- /contents/images/g1gc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/g1gc.png -------------------------------------------------------------------------------- /contents/images/generics.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/generics.png -------------------------------------------------------------------------------- /contents/images/graph-vs-tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/graph-vs-tree.png -------------------------------------------------------------------------------- /contents/images/hashtable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/hashtable.png -------------------------------------------------------------------------------- /contents/images/inner-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/inner-join.png -------------------------------------------------------------------------------- /contents/images/isolation-level.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/isolation-level.png -------------------------------------------------------------------------------- /contents/images/java-collections-framework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/java-collections-framework.png -------------------------------------------------------------------------------- /contents/images/java_boxing_unboxing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/java_boxing_unboxing.png -------------------------------------------------------------------------------- /contents/images/jdbc-component-interface-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/jdbc-component-interface-diagram.png -------------------------------------------------------------------------------- /contents/images/jdbc1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/jdbc1.png -------------------------------------------------------------------------------- /contents/images/jdbc_basic_cycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/jdbc_basic_cycle.png -------------------------------------------------------------------------------- /contents/images/join-table.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/join-table.png -------------------------------------------------------------------------------- /contents/images/jvm-runtime-data-areas.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/jvm-runtime-data-areas.png -------------------------------------------------------------------------------- /contents/images/left-outer-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/left-outer-join.png -------------------------------------------------------------------------------- /contents/images/memcached-usage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/memcached-usage.png -------------------------------------------------------------------------------- /contents/images/multi-thread.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/multi-thread.png -------------------------------------------------------------------------------- /contents/images/natural-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/natural-join.png -------------------------------------------------------------------------------- /contents/images/non-sync.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/non-sync.png -------------------------------------------------------------------------------- /contents/images/osi-7-layer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/osi-7-layer.png -------------------------------------------------------------------------------- /contents/images/osi-pdu.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/osi-pdu.png -------------------------------------------------------------------------------- /contents/images/partitioning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/partitioning.png -------------------------------------------------------------------------------- /contents/images/persistence-layer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/persistence-layer.png -------------------------------------------------------------------------------- /contents/images/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/process.png -------------------------------------------------------------------------------- /contents/images/right-outer-join.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/right-outer-join.png -------------------------------------------------------------------------------- /contents/images/separatingChaining.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/separatingChaining.png -------------------------------------------------------------------------------- /contents/images/session-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/session-process.png -------------------------------------------------------------------------------- /contents/images/singleton-example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/singleton-example.png -------------------------------------------------------------------------------- /contents/images/strategy-pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/strategy-pattern.png -------------------------------------------------------------------------------- /contents/images/tcp-virtual-circuit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/tcp-virtual-circuit.png -------------------------------------------------------------------------------- /contents/images/tcpheader.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/tcpheader.png -------------------------------------------------------------------------------- /contents/images/template-method-pattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/template-method-pattern.png -------------------------------------------------------------------------------- /contents/images/thread.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/thread.png -------------------------------------------------------------------------------- /contents/images/transaction-status.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/transaction-status.png -------------------------------------------------------------------------------- /contents/images/types-of-designpattern.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/types-of-designpattern.png -------------------------------------------------------------------------------- /contents/images/types-of-partitioning.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/types-of-partitioning.png -------------------------------------------------------------------------------- /contents/images/udp-datagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/udp-datagram.png -------------------------------------------------------------------------------- /contents/images/udpheader.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/WeareSoft/tech-interview/a69ac28e52aca2fa7ef8a23efb8cd7429eb40e28/contents/images/udpheader.png -------------------------------------------------------------------------------- /contents/javascript.md: -------------------------------------------------------------------------------- 1 | # 8. JavaScript 2 | **:book: Contents** 3 | * [JavaScript Event Loop](#javascript-event-loop) 4 | * [함수 선언식과 함수 표현식](#함수-선언식과-함수-표현식) 5 | * [변수 선언 방식 const와 let](#변수-선언-방식-const와-let) 6 | * [화살표 함수](#화살표-함수) 7 | * [향상된 객체 리터럴](#향상된-객체-리터럴) 8 | * [Modules](#modules) 9 | * [Destructuring](#destructuring) 10 | * [Spread Operator](#spread-operator) 11 | * [Hoisting](#hoisting) 12 | * [Closure](#closure) 13 | * [this](#this) 14 | * [Promise](#promise) 15 | * [Async/Await](#async-await) 16 | 17 | --- 18 | 19 | ### JavaScript Event Loop 20 | 21 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 22 | > - []() 23 | 24 | ### 함수 선언식과 함수 표현식 25 | - 함수 26 | ```js 27 | // function statement 28 | function sum() { 29 | return 10 + 20; 30 | } 31 | ``` 32 | - 함수 표현식 33 | ```js 34 | // function expression (; 존재) 35 | var sum = function () { 36 | return 10 + 20; 37 | }; 38 | ``` 39 | 40 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 41 | > - []() 42 | 43 | ### 변수 선언 방식 const와 let 44 | - 블록 단위 `{}`로 변수의 범위가 제한되었음 45 | ```js 46 | let sum = 0; 47 | for (let i=1; i<=5; i++) { 48 | sum = sum + i; 49 | } 50 | console.log(sum); // 10 51 | console.log(i); // Uncaught ReferenceError: i is not defined 52 | ``` 53 | - `const` 54 | - 한번 선언한 값에 대해서 변경할 수 없음(상수 개념) 55 | ```js 56 | /* 예시 */ 57 | const a = 10; 58 | a = 20; // Uncaught TypeError: Assignment to constant variable 59 | 60 | /* [주의!] 하지만, 객체나 배열의 내부는 변경할 수 있다. */ 61 | const a = {}; 62 | a.num = 10; 63 | console.log(a); // {num: 10} 64 | 65 | const b = []; 66 | b.push(20); 67 | console.log(b); // [20] 68 | ``` 69 | - `let` 70 | - 한번 선언한 값에 대해서 다시 선언할 수 없음(메모리에 할당하면 다시 할당하지 못함), 변경은 가능 71 | - 간단한 scope 예시 72 | ```js 73 | function f() { 74 | { 75 | let x; 76 | { 77 | // 새로운 블록 안에 새로운 x의 스코프가 생김 78 | const x = "sneaky"; 79 | x = "foo"; // 위에 이미 const로 x를 선언했으므로 다시 값을 대입하면 Error 80 | } 81 | // 이전 블록 범위로 돌아왔기 때문에 'let x'에 해당하는 메모리에 값을 대입 82 | x = "bar"; 83 | let x = "inner"; // SyntaxError: Identifier 'x' has already been declared 84 | } 85 | } 86 | ``` 87 | 88 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 89 | > - []() 90 | 91 | ### 화살표 함수 92 | - **Arrow Function**, Fat Arrow 93 | - 함수를 정의할 때 `function`이라는 키워드를 사용하지 않고 `=>`로 대체 94 | - 흔히 사용하는 **콜백 함수**의 문법을 간결화 95 | ```js 96 | // ES5 함수 정의 방식 (function expression) 97 | var sum = function (a, b) { 98 | return a + b; 99 | }; 100 | 101 | // ES6 함수 정의 방식 102 | var sum = (a, b) => { 103 | return a + b; 104 | } 105 | sum (10, 20); 106 | ``` 107 | ```js 108 | /* 화살표 함수 사용 예시 */ 109 | 110 | var arr = ["a", "b", "c"]; 111 | // ES5 112 | arr.forEach(function(value){ // 익명 함수 113 | console.log(value); // a, b, c 114 | }); 115 | // ES6 116 | arr.forEach(value => console.log(value)); // a, b, c 117 | ``` 118 | 119 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 120 | > - []() 121 | 122 | ### 향상된 객체 리터럴 123 | - **Enhanced Object Literals** 124 | - 객체의 속성을 메서드로 사용할 때 `function`예약어를 생략하고 생성 가능 125 | ```js 126 | // 객체 127 | var dictionary = { 128 | words: 100, 129 | /* 속성 메서드: 속성에 function을 연결 */ 130 | // ES5 131 | lookup: function() { 132 | console.log("find words"); 133 | }, 134 | // ES6 - ': funtion' 생략 135 | lookup() { 136 | console.log("find words"); 137 | } 138 | }; 139 | ``` 140 | - 객체의 속성명과 값 명이 동일할 때 아래와 같이 축약 가능 141 | ```js 142 | var figures = 10; 143 | var dictionary = { 144 | // figures: figures, 145 | figures 146 | }; 147 | ``` 148 | 149 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 150 | > - []() 151 | 152 | ### Modules 153 | - **자바스크립트 모듈화 방법** 154 | - 자바스크립트 모듈(특정 기능을 수행하는 한 단위) 로더 라이브러리(AMD, Commons JS)기능을 js언어 자체에서 지원 155 | - 모듈화 하는 이유 156 | - 재사용성 157 | - 변수 scope 충돌 방지 158 | - 안정성있는 코딩 가능 159 | - Modules: lib에서 지원하던 것을 언어 차원에서 지원함으로써 개발자들의 수고를 덜어줌 160 | - 호출되기 전까지는 코드 실행과 동작을 하지 않는 특징이 있음 161 | ```js 162 | // libs/math.js 163 | export function sum(x, y) { 164 | return x + y; 165 | } 166 | export var pi = 3.141592; 167 | 168 | // main.js 169 | import {sum} from libs/math.js; 170 | sum(1, 2); 171 | ``` 172 | - `defualt` export 173 | - 하나의 파일에서 하나만 export 할 수 있다. 174 | - encapsulation으로 모듈화 175 | - 다른 파일에서 가져다가 사용할 때 원하는 이름을 설정하여 사용할 수 있다. 176 | ```js 177 | // util.js 178 | export default function(x) { 179 | return console.log(x); 180 | } 181 | // main.js 182 | import util from `util.js`; 183 | console.log(util); // function(x) {return console.log(x);} 184 | ``` 185 | 186 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 187 | > - []() 188 | 189 | ### Destructuring 190 | - **디스트럭처링 (Destructuring)** 191 | 192 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 193 | > - []() 194 | 195 | ### Spread Operator 196 | - **전개 연산자 (Spread Operator)** 197 | 198 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 199 | > - []() 200 | 201 | ### Hoisting 202 | - Hoisting(끌어올리다.) 203 | - Hoisting이란 선언한 함수와 변수를 해석기가 가장 상단에 있는 것처럼 인식한다. 204 | - js 해석기는 코드의 라인 순서와 관계 없이 **함수 선언식**(함수 표현식 X)과 **변수**를 위한 메모리 공간을 먼저 확보한다. 205 | - 따라서, `function a()`와 `var`는 코드의 최상단으로 끌어 올려진 것(hoisted)처럼 보인다. 206 | ```js 207 | function willbeoverridden() { 208 | return 10; 209 | } 210 | willbeoverridden(); // 5 211 | function willbeoverridden() { 212 | return 5; 213 | } 214 | ``` 215 | ```js 216 | /* 예시 */ 217 | var sum = 5; 218 | sum = sum + i; 219 | function sumAllNumbers() { 220 | // ... 221 | } 222 | var i = 10; 223 | 224 | /* js 해석기에 따른 순서 재조정 결과 */ 225 | // #1 - 함수 선언식과 변수 선언을 hoisting 226 | var sum; 227 | function sumAllNumbers() { 228 | // ... 229 | } 230 | var i; 231 | // #2 - 변수 대입 및 할당 232 | sum = 5; 233 | sum = sum + i; 234 | i = 10; 235 | ``` 236 | 237 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 238 | > - []() 239 | 240 | ### Closure 241 | 242 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 243 | > - []() 244 | 245 | ### this 246 | 247 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 248 | > - []() 249 | 250 | ### Promise 251 | 252 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 253 | > - []() 254 | 255 | ### Async Await 256 | 257 | > :arrow_double_up:[Top](#8-javascript) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#8-javascript) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 258 | > - []() 259 | 260 | --- 261 | 262 | ## Reference 263 | > - []() 264 | 265 | 266 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 267 | -------------------------------------------------------------------------------- /contents/network.md: -------------------------------------------------------------------------------- 1 | # 2. Network 2 | **:book: Contents** 3 | - [2. Network](#2-network) 4 | - [OSI 7계층](#osi-7계층) 5 | - [TCP IP의 개념](#tcp-ip의-개념) 6 | - [TCP와 UDP](#tcp와-udp) 7 | - [TCP와 UDP의 헤더 분석](#tcp와-udp의-헤더-분석) 8 | - [TCP의 3 way handshake와 4 way handshake](#tcp의-3-way-handshake와-4-way-handshake) 9 | - [:question:TCP 관련 질문 1](#questiontcp-관련-질문-1) 10 | - [:question:TCP 관련 질문 2](#questiontcp-관련-질문-2) 11 | - [:question:TCP 관련 질문 3](#questiontcp-관련-질문-3) 12 | - [HTTP와 HTTPS](#http와-https) 13 | - [HTTP 요청 응답 헤더](#http-요청-응답-헤더) 14 | - [HTTP와 HTTPS 동작 과정](#http와-https-동작-과정) 15 | - [CORS란](#cors란) 16 | - [GET 메서드와 POST 메서드](#get-메서드와-post-메서드) 17 | - [쿠키와 세션](#쿠키와-세션) 18 | - [DNS](#dns) 19 | - [REST와 RESTful의 개념](#rest와-restful의-개념) 20 | - [소켓이란](#소켓이란) 21 | - [Socket.io와 WebSocket의 차이](#socketio와-websocket의-차이) 22 | - [Frame Packet Segment Datagram](#frame-packet-segment-datagram) 23 | - [PDU (Protocol Data Unit)](#pdu-protocol-data-unit) 24 | - [데이터 캡슐화](#데이터-캡슐화) 25 | - [Reference](#reference) 26 | - [:house: Home](#house-home) 27 | 28 | 29 | --- 30 | 31 | ### OSI 7계층 32 | * OSI(Open Systems Interconnection Reference Model)란 33 | 34 | * 국제표준화기구(ISO)에서 개발한 모델로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것이다. 35 | * 이 모델은 프로토콜을 기능별로 나눈 것이다. 36 | * 각 계층은 하위 계층의 기능만을 이용하고, 상위 계층에게 기능을 제공한다. 37 | * '프로토콜 스택' 혹은 '스택'은 이러한 계층들로 구성되는 프로토콜 시스템이 구현된 시스템을 가리키는데, 프로토콜 스택은 하드웨어나 소프트웨어 혹은 둘의 혼합으로 구현될 수 있다. 38 | * 일반적으로 하위 계층들은 하드웨어로, 상위 계층들은 소프트웨어로 구현된다. 39 | 1. 물리 계층(Physical layer) 40 | * 네트워크의 기본 네트워크 하드웨어 전송 기술을 이룬다. 41 | * 네트워크의 높은 수준의 기능의 논리 데이터 구조를 기초로 하는 필수 계층이다. 42 | * 전송 단위는 Bit이다. 43 | 2. 데이터 링크 계층(Data link layer) 44 | * 포인트 투 포인트(Point to Point) 간 신뢰성있는 전송을 보장하기 위한 계층으로 CRC 기반의 오류 제어와 흐름 제어가 필요하다. 45 | * 주소 값은 물리적으로 할당 받는데, 이는 네트워크 카드가 만들어질 때부터 맥 주소(MAC address)가 정해져 있다는 뜻이다. 46 | * 데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다. 47 | * 데이터 전송 단위는 Frame이다. 48 | 3. 네트워크 계층(Network layer) 49 | * 여러개의 노드를 거칠때마다 경로를 찾아주는 역할을 하는 계층으로 다양한 길이의 데이터를 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질(QoS)을 제공하기 위한 기능적, 절차적 수단을 제공한다. 50 | * 네트워크 계층은 라우팅, 흐름 제어, 세그멘테이션(segmentation/desegmentation), 오류 제어, 인터네트워킹(Internetworking) 등을 수행한다. 51 | * 논리적인 주소 구조(IP), 곧 네트워크 관리자가 직접 주소를 할당하는 구조를 가지며, 계층적(hierarchical)이다. 52 | * 데이터 전송 단위는 Datagram(Packet)이다. 53 | 4. 전송 계층(Transport layer) 54 | * 양 끝단(End to end)의 사용자들이 신뢰성있는 데이터를 주고 받을 수 있도록 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다. 55 | * 시퀀스 넘버 기반의 오류 제어 방식을 사용한다. 56 | * 전송 계층은 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고(stateful), 연결 기반(connection oriented)이다. (이는 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패킷들을 다시 전송한다는 것을 뜻한다.) 57 | * 가장 잘 알려진 전송 계층의 예는 TCP이다. 58 | * 데이터 전송 단위는 Segment이다. 59 | 5. 세션 계층(Session layer) 60 | * 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다. 61 | * 동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex)의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다. 62 | * 이 계층은 TCP/IP 세션을 만들고 없애는 책임을 진다. 63 | 6. 표현 계층(Presentation layer) 64 | * 코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어 준다. 65 | * MIME 인코딩이나 암호화 등의 동작이 이 계층에서 이루어진다. 66 | 7. 응용 계층(Application layer) 67 | * 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다. 68 | * 일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다. 69 | 70 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 71 | > - [https://ko.wikipedia.org/wiki/OSI_%EB%AA%A8%ED%98%95](https://ko.wikipedia.org/wiki/OSI_%EB%AA%A8%ED%98%95) 72 | 73 | ### TCP IP의 개념 74 | 76 | 77 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 78 | > - []() 79 | 80 | ### TCP와 UDP 81 | * 네트워크 계층 중 **전송 계층에서 사용하는 프로토콜** 82 | * TCP(Transmission Control Protocol) 83 | 84 | * 인터넷 상에서 데이터를 메세지의 형태(**세그먼트** 라는 블록 단위)로 보내기 위해 IP와 함께 사용하는 프로토콜이다. 85 | * TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리한다. 86 | * **연결형 서비스로** 가상 회선 방식을 제공한다. 87 | * 3-way handshaking과정을 통해 연결을 설정하고, 4-way handshaking을 통해 연결을 해제한다. 88 | * 흐름제어 및 혼잡제어를 제공한다. 89 | * 흐름제어 90 | * 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것 91 | * 송신하는 곳에서 감당이 안되게 많은 데이터를 빠르게 보내 수신하는 곳에서 문제가 일어나는 것을 막는다. 92 | * 혼잡제어 93 | * 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것 94 | * 정보의 소통량이 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막는다. 95 | * 높은 신뢰성을 보장한다. 96 | * UDP보다 속도가 느리다. 97 | * 전이중(Full-Duplex), 점대점(Point to Point) 방식이다. 98 | * 전이중 99 | * 전송이 양방향으로 동시에 일어날 수 있다. 100 | * 점대점 101 | * 각 연결이 정확히 2개의 종단점을 가지고 있다. 102 | * 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다. 103 | * 연속성보다 신뢰성있는 전송이 중요할 때에 사용된다. 104 | * UDP(User Datagram Protocol) 105 | 106 | * 데이터를 **데이터그램** 단위로 처리하는 프로토콜이다. 107 | * **비연결형 서비스로** 데이터그램 방식을 제공한다. 108 | * 연결을 위해 할당되는 논리적인 경로가 없다. 109 | * 그렇기 때문에 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 된다. 110 | * 이렇게 데이터를 서로 다른 경로로 독립적으로 처리한다. 111 | * 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다. 112 | * UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다. 113 | * 신뢰성이 낮다. 114 | * TCP보다 속도가 빠르다. 115 | * 신뢰성보다는 연속성이 중요한 서비스, 예를 들면 실시간 서비스(streaming)에 사용된다. 116 | * 참고 117 | * UDP와 TCP는 각각 별도의 포트 주소 공간을 관리하므로 같은 포트 번호를 사용해도 무방하다. 즉, 두 프로토콜에서 동일한 포트 번호를 할당해도 서로 다른 포트로 간주한다. 118 | * 또한 같은 모듈(UDP or TCP) 내에서도 클라이언트 프로그램에서 동시에 여러 커넥션을 확립한 경우에는 서로 다른 포트 번호를 동적으로 할당한다. (동적할당에 사용되는 포트번호는 49,152~65,535이다.) 119 | 120 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 121 | > - [http://mangkyu.tistory.com/15](http://mangkyu.tistory.com/15) 122 | > - [http://ddooooki.tistory.com/21](http://ddooooki.tistory.com/21) 123 | > - [http://www.inven.co.kr/webzine/news/?news=165870](http://www.inven.co.kr/webzine/news/?news=165870) 124 | 125 | ### TCP와 UDP의 헤더 분석 126 | 127 | #### TCP Header 128 | * TCP는 상위계층으로부터 데이터를 받아 **헤더**를 추가해 IP로 전송 129 | 130 | ![tcpheader](./images/tcpheader.png) 131 | 132 | |필드|내용|크기(bits)| 133 | |----|----|----| 134 | |Source Port, Destination Port|TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당되는 포트 주소|16| 135 | |Sequence Number|송신자가 지정하는 순서 번호, **전송되는 바이트 수** 기준으로 증가
SYN = 1 : 초기 시퀀스 번호. ACK 번호는 이 값에 + 1|32| 136 | |Acknowledgment(ACK) Number|수신 프로세스가 제대로 **수신한 바이트의 수** 응답 용|32| 137 | |Header Length(Data Offset)|TCP 헤더 길이를 4바이트 단위로 표시(최소 20, 최대 60 바이트)|4| 138 | |Resv(Reserved)|나중을 위해 0으로 채워진 예약 필드|6| 139 | |Flag Bit|SYN, ACK, FIN 등 제어 번호(아래 표 참고)|6| 140 | |Window Size|**수신 윈도우의 버퍼 크기** 지정(0이면 송신 중지). 상대방의 확인 없이 전송 가능한 최대 바이트 수|16| 141 | |TCP Checksum|헤더와 데이터의 에러 확인 용도|16| 142 | |Urgent Pointer(긴급 위치)|현재 순서 번호부터 표시된 바이트까지 긴급한 데이터임을 표시, URG 플래그 비트가 지정된 경우에만 유효|16| 143 | |Options|추가 옵션 있을 경우 표시|0~40| 144 | 145 | * Flag Bit 146 | 147 | |종류|내용| 148 | |----|----| 149 | |URG|긴급 위치 필드 유효 여부 설정| 150 | |ACK|응답 유효 여부 설정. 최초의 SYN 패킷 이후 모든 패킷은 ACK 플래그 설정 필요. 데이터를 잘 받았으면 긍정 응답으로 ACK(=SYN+1) 전송| 151 | |PSH|수신측에 버퍼링된 데이터를 상위 계층에 즉시 전달할 때| 152 | |RST|연결 리셋 응답 혹은 유효하지 않은 세그먼트 응답| 153 | |SYN|연결 설정 요청. 양쪽이 보낸 최초 패킷에만 SYN 플래그 설정| 154 | |FIN|연결 종료 의사 표시| 155 | 156 | #### UDP Header 157 | ![udpheader](./images/udpheader.png) 158 | 159 | |필드|내용|크기(bits)| 160 | |----|----|----| 161 | |Source Port, Destination Port|송수신 애플리케이션의 포트 번호|16| 162 | |Length|헤더와 데이터 포함 전체 길이|16| 163 | |Checksum|헤더와 데이터의 에러 확인 용도. UDP는 에러 복구를 위한 필드가 불필요하기 때문에 TCP 헤더에 비해 간단|16| 164 | 165 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 166 | > - [TCP 와 UDP 차이를 자세히 알아보자](https://velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4) 167 | > - [TCP, UDP header](https://cysecguide.blogspot.com/2018/04/tcp-udp-header.html) 168 | > - [TCP 와 UDP [동작원리/헤더/차이점]](https://m.blog.naver.com/PostView.nhn?blogId=minki0127&logNo=220804490550&proxyReferer=https:%2F%2Fwww.google.com%2F) 169 | > - [https://idchowto.com/?p=18352](https://idchowto.com/?p=18352) 170 | > - [https://m.blog.naver.com/PostView.nhn?blogId=koromoon&logNo=120162515270&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F](https://m.blog.naver.com/PostView.nhn?blogId=koromoon&logNo=120162515270&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F) 171 | 172 | ### TCP의 3 way handshake와 4 way handshake 173 | * TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 연결을 설정하여 **신뢰성을 보장하는 연결형 서비스** 이다. 174 | * 3-way handshake 란 175 | * TCP 통신을 이용하여 데이터를 전송하기 위해 네트워크 **연결을 설정(Connection Establish)** 하는 과정 176 | * 양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 한 쪽이 다른 쪽이 준비되었다는 것을 알 수 있도록 한다. 177 | * 즉, TCP/IP 프로토콜을 이용해서 통신을 하는 응용 프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다. 178 | * A 프로세스(Client)가 B 프로세스(Server)에 연결을 요청 179 | 180 | 1. A -> B: SYN 181 | * 접속 요청 프로세스 A가 연결 요청 메시지 전송 (SYN) 182 | * 송신자가 최초로 데이터를 전송할 때 Sequence Number를 임의의 랜덤 숫자로 지정하고, SYN 플래그 비트를 1로 설정한 세그먼트를 전송한다. 183 | * PORT 상태 - B: LISTEN, A: CLOSED 184 | 2. B -> A: SYN + ACK 185 | * 접속 요청을 받은 프로세스 B가 요청을 수락했으며, 접속 요청 프로세스인 A도 포트를 열어 달라는 메시지 전송 (SYN + ACK) 186 | * 수신자는 Acknowledgement Number 필드를 (Sequence Number + 1)로 지정하고, SYN과 ACK 플래그 비트를 1로 설정한 세그먼트를 전송한다. 187 | * PORT 상태 - B: SYN_RCV, A: CLOSED 188 | 3. A -> B: ACK 189 | * PORT 상태 - B: SYN_RCV, A: ESTABLISHED 190 | * 마지막으로 접속 요청 프로세스 A가 수락 확인을 보내 연결을 맺음 (ACK) 191 | * 이때, 전송할 데이터가 있으면 이 단계에서 데이터를 전송할 수 있다. 192 | * PORT 상태 - B: ESTABLISHED, A: ESTABLISHED 193 | * 4-way handshake 란 194 | * TCP의 **연결을 해제(Connection Termination)** 하는 과정 195 | * A 프로세스(Client)가 B 프로세스(Server)에 연결 해제를 요청 196 | 197 | 1. A -> B: FIN 198 | * 프로세스 A가 연결을 종료하겠다는 FIN 플래그를 전송 199 | * 프로세스 B가 FIN 플래그로 응답하기 전까지 연결을 계속 유지 200 | 2. B -> A: ACK 201 | * 프로세스 B는 일단 확인 메시지를 보내고 자신의 통신이 끝날 때까지 기다린다. (이 상태가 TIME_WAIT 상태) 202 | * 수신자는 Acknowledgement Number 필드를 (Sequence Number + 1)로 지정하고, ACK 플래그 비트를 1로 설정한 세그먼트를 전송한다. 203 | * 그리고 자신이 전송할 데이터가 남아있다면 이어서 계속 전송한다. 204 | 3. B -> A: FIN 205 | * 프로세스 B가 통신이 끝났으면 연결 종료 요청에 합의한다는 의미로 프로세스 A에게 FIN 플래그를 전송 206 | 4. A -> B: ACK 207 | * 프로세스 A는 확인했다는 메시지를 전송 208 | * 참고 - ***포트(PORT) 상태 정보*** 209 | * CLOSED: 포트가 닫힌 상태 210 | * LISTEN: 포트가 열린 상태로 연결 요청 대기 중 211 | * SYN_RCV: SYNC 요청을 받고 상대방의 응답을 기다리는 중 212 | * ESTABLISHED: 포트 연결 상태 213 | * 참고 - ***플래그 정보*** 214 | * TCP Header에는 CONTROL BIT(플래그 비트, 6bit)가 존재하며, 각각의 bit는 "URG-ACK-PSH-RST-SYN-FIN"의 의미를 가진다. 215 | * 즉, 해당 위치의 bit가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다. 216 | * SYN(Synchronize Sequence Number) / 000010 217 | * 연결 설정. Sequence Number를 랜덤으로 설정하여 세션을 연결하는 데 사용하며, 초기에 Sequence Number를 전송한다. 218 | * ACK(Acknowledgement) / 010000 219 | * 응답 확인. 패킷을 받았다는 것을 의미한다. 220 | * Acknowledgement Number 필드가 유효한지를 나타낸다. 221 | * 양단 프로세스가 쉬지 않고 데이터를 전송한다고 가정하면 최초 연결 설정 과정에서 전송되는 첫 번째 세그먼트를 제외한 모든 세그먼트의 ACK 비트는 1로 지정된다고 생각할 수 있다. 222 | * FIN(Finish) / 000001 223 | * 연결 해제. 세션 연결을 종료시킬 때 사용되며, 더 이상 전송할 데이터가 없음을 의미한다. 224 | 225 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 226 | > - [http://needjarvis.tistory.com/157](http://needjarvis.tistory.com/157) 227 | > - [http://hyeonstorage.tistory.com/286](http://hyeonstorage.tistory.com/286) 228 | 229 | #### :question:TCP 관련 질문 1 230 | * Q. TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유? 231 | * A. Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문이다. 232 | * [관련 Reference](http://ddooooki.tistory.com/21) 233 | 234 | #### :question:TCP 관련 질문 2 235 | * Q. 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까? 236 | * A. 이러한 현상에 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정시간(Default: 240sec)동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT 과정) 237 | * [관련 Reference](http://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake) 238 | 239 | #### :question:TCP 관련 질문 3 240 | * Q. 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유? 241 | * A. Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순처적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정한다. 242 | * [관련 Reference](http://asfirstalways.tistory.com/356) 243 | 244 | ### HTTP와 HTTPS 245 | - HTTP 프로토콜 246 | - 개념 247 | - HyperText Transfer Protocol 248 | - 웹 상에서 클라이언트와 서버 간에 요청/응답(request/response)으로 정보를 주고 받을 수 있는 프로토콜 249 | - 특징 250 | - 주로 HTML 문서를 주고받는 데에 쓰인다. 251 | - TCP와 UDP를 사용하며, **80번 포트**를 사용한다. 252 | - 1) 비연결(Connectionless) 253 | - 클라이언트가 요청을 서버에 보내고 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊긴다. 254 | - 2) 무상태(Stateless) 255 | - 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다. 256 | - HTTPS 프로토콜 257 | - 개념 258 | - HyperText Transfer Protocol over Secure Socket Layer 259 | - 또는 HTTP over TLS, HTTP over SSL, HTTP Secure 260 | - 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전의 프로토콜 261 | - 특징 262 | - HTTPS의 기본 TCP/IP 포트로 **443번 포트**를 사용한다. 263 | - HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, 웹 상에서 정보를 암호화하는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 264 | - TLS(Transport Layer Security) 프로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것이다. 265 | - 두 프로토콜의 주요 목표는 기밀성(사생활 보호), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공하는 것이다. 266 | - 따라서 데이터의 적절한 보호를 보장한다. 267 | - 보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. 268 | - 금융 정보나 메일 등 중요한 정보를 주고받는 것은 HTTPS를, 아무나 봐도 상관 없는 페이지는 HTTP를 사용한다. 269 | - HTTPS가 필요한 이유? 270 | - 클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다. 271 | - 웹 페이지(HTML)는 텍스트이고, HTTP를 통해 이런 텍스트 정보를 교환하는 것이다. 272 | - 이때 주고받는 텍스트 정보에 주민등록번호나 비밀번호와 같이 민감한 정보가 포함된 상태에서 네트워크 상에서 중간에 제3자가 정보를 가로챈다면 보안상 큰 문제가 발생한다. 273 | - 즉, 중간에서 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용하는 것이다. 274 | - HTTPS의 원리 275 | - **[공개키 알고리즘 방식](https://github.com/WeareSoft/tech-interview/blob/master/contents/security.md#대칭키와-비대칭키-차이)** 276 | - 암호화, 복호화시킬 수 있는 서로 다른 키(공개키, 개인키)를 이용한 암호화 방법 277 | - 공개키: 모두에게 공개. 공캐키 저장소에 등록 278 | - 개인키(비공개키): 개인에게만 공개. 클라이언트-서버 구조에서는 서버가 가지고 있는 비공개키 279 | - 클라이언트 -> 서버 280 | - 사용자의 데이터를 **공개키로 암호화** (공개키를 얻은 인증된 사용자) 281 | - 서버로 전송 (데이터를 가로채도 개인키가 없으므로 **복호화할 수 없음**) 282 | - 서버의 **개인키를 통해 복호화**하여 요청 처리 283 | - HTTPS의 장단점 284 | - 장점 285 | - 네트워크 상에서 열람, 수정이 불가능하므로 안전하다. 286 | - 단점 287 | - 암호화를 하는 과정이 웹 서버에 부하를 준다. 288 | - HTTPS는 설치 및 인증서를 유지하는데 추가 비용이 발생한다. 289 | - HTTP에 비해 느리다. 290 | - 인터넷 연결이 끊긴 경우 재인증 시간이 소요된다. 291 | - HTTP는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있다. 292 | - 그러나 HTTPS의 경우에는 소켓(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 HTTPS 인증이 필요하다. 293 | 294 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 295 | > - [https://ko.wikipedia.org/wiki/HTTPS](https://ko.wikipedia.org/wiki/HTTPS) 296 | > - [https://jeong-pro.tistory.com/89](https://jeong-pro.tistory.com/89) 297 | > - [https://m.blog.naver.com/reviewer__/221294104297](https://m.blog.naver.com/reviewer__/221294104297) 298 | > - [https://www.ibm.com/support/knowledgecenter/ko/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10630_.htm](https://www.ibm.com/support/knowledgecenter/ko/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10630_.htm) 299 | 300 | 301 | ### HTTP 요청 응답 헤더 302 | - HTTP 헤더 내 일반 헤더(General Header) 항목 303 | - 요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의(기본적인) 헤더 항목 304 | - 주요 항목들 305 | - **Date**: HTTP 메시지를 생성한 일시 (RFC 1123에서 규정) 306 | - `Date: Sat, 2 Oct 2018 02:00:12 GMT` 307 | - **Connection**: 클라이언트와 서버 간 연결에 대한 옵션 설정(다소 모호한 복잡성 있음) 308 | - `Connection: close` => 현재 HTTP 메시지 직후에 TCP 접속을 끊는다는 것을 알림 309 | - `Connection: Keep-Alive` => 현재 TCP 커넥션을 유지 310 | - **Cache-Control** 311 | - **Pragma** 312 | - **Trailer** 313 | - HTTP 헤더 내 엔터티/개체 헤더 (Entity Header) 항목 314 | - 요청 및 응답 메시지 모두에서 사용 가능한 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명 헤더 315 | - 주요 항목들 316 | - **Content-Type**: 해당 개체에 포함되는 미디어 타입 정보 317 | - 컨텐츠의 타입(MIME 미디어 타입) 및 문자 인코딩 방식(EUC-KR,UTF-8 등)을 지정 318 | - 타입 및 서브타입(type/subtype)으로 구성 319 | - `Content-Type: text/html; charset-latin-1` => 해당 개체가 html으로 표현된 텍스트 문서이고, iso-latin-1 문자 인코딩 방식으로 표현됨 320 | - **Content-Language**: 해당 개체와 가장 잘 어울리는 사용자 언어(자연언어) 321 | - **Content-Encoding**: 해당 개체 데이터의 압축 방식 322 | - `Content-Encoding: gzip, deflate` 323 | - 만일 압축이 시행되었다면, Content-Encoding 및 Content-Length 2개 항목을 토대로 압축 해제 가능 324 | - **Content-Length**: 전달되는 해당 개체의 바이트 길이 또는 크기(10진수) 325 | - 응답 메시지 Body의 길이를 지정하거나, 특정 지정된 개체의 길이를 지정함 326 | - **Content-Location**: 해당 개체가 실제 어디에 위치하는가를 알려줌 327 | - **Content-Disposition**: 응답 Body를 브라우저가 어떻게 표시해야 할지 알려주는 헤더 328 | - inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드 329 | - `Content-Disposition: inline` 330 | - `Content-Disposition: attachment; filename='filename.csv'` 331 | - 다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다. 332 | - 파일용 서버인 경우 이 태그를 자주 사용 333 | - **Content-Security-Policy**: 다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 명시 334 | - *XSS 공격*에 대한 방어 가능 (허용한 외부 소스만 지정 가능) 335 | - `Content-Security-Policy: default-src https:` => https를 통해서만 파일을 가져옴 336 | - `Content-Security-Policy: default-src 'self'` => 자신의 도메인의 파일들만 가져옴 337 | - `Content-Security-Policy: default-src 'none'` => 파일을 가져올 수 없음 338 | - **Location**: 리소스가 리다이렉트(redirect)된 때에 이동된 주소, 또는 새로 생성된 리소스 주소 339 | - 300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려주는 헤더 340 | - 새로 생성된 경우에 HTTP 상태 코드 `201 Created`가 반환됨 341 | - `HTTP/1.1 302 Found Location: /` 342 | - 이런 응답이 왔다면 브라우저는 / 주소로 redirect한다. 343 | - **Last-Modified**: 리소스를 마지막으로 갱신한 일시 344 | - HTTP 헤더 내 요청 헤더 (Request Header) 항목 345 | - 요청 헤더는 HTTP 요청 메시지 내에서만 나타나며 가장 방대하다. 346 | - 주요 항목들 347 | - **Host**: 요청하는 호스트에 대한 호스트명 및 포트번호 (***필수***) 348 | - Host 필드에 도메인명 및 호스트명 모두를 포함한 전체 URI(FQDN) 지정 필요 349 | - 이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트가 구축 가능 350 | - **User-Agent**: 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보 351 | - **From**: 클라이언트 사용자 메일 주소 352 | - 주로 검색엔진 웹 로봇의 연락처 메일 주소를 나타냄 353 | - 때로는, 이 연락처 메일 주소를 User-Agent 항목에 두는 경우도 있음 354 | - **Cookie**: 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보 355 | - **Referer**: 바로 직전에 머물었던 웹 링크 주소 356 | - **If-Modified-Since**: 제시한 일시 이후로만 변경된 리소스를 취득 요청 357 | - **Authorization**: 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더 358 | - 토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자를 전송 359 | - **Origin** 360 | - 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄 361 | - 여기서 요청을 보낸 주소와 받는 주소가 다르면 *CORS 에러*가 발생 362 | - 응답 헤더의 **Access-Control-Allow-Origin**와 관련 363 | - 다음 4개는 주로 HTTP 메세지 Body의 속성 또는 내용 협상용 항목들 364 | - **Accept**: 클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알림 365 | - `Accept: */*` => 어떤 미디어 타입도 가능 366 | - `Accept: image/*` => 모든 이미지 유형 367 | - **Accept-Charset**: 클라이언트 자신이 원하는 문자 집합 368 | - **Accept-Encoding**: 클라이언트 자신이 원하는 문자 인코딩 방식 369 | - **Accept-Language**: 클라이언트 자신이 원하는 가능한 언어 370 | - 각각이 HTTP Entity Header 항목 중에 `Content-Type, Content-Type charset-xxx, Content-Encoding, Content-Language`과 일대일로 대응됨 371 | - HTTP 헤더 내 응답 헤더 (Response Header) 항목 372 | - 특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때, 이에 응답한다. 373 | - 주요 항목들 374 | - **Server**: 서버 소프트웨어 정보 375 | - **Accept-Range** 376 | - **Set-Cookie**: 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정) 377 | - **Expires**: 리소스가 지정된 일시까지 캐시로써 유효함 378 | - **Age**: 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 알려줌(초 단위) 379 | - **ETag**: HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그 380 | - **Proxy-authenticate** 381 | - **Allow**: 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타냄 382 | - 때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목 383 | - OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의 384 | - `Allow: GET,HEAD` => 웹 서버측이 제공 가능한 HTTP 메서드는 GET,HEAD 뿐임을 알림 (405 Method Not Allowed 에러와 함께) 385 | - **Access-Control-Allow-Origin**: 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 *CORS 에러*가 발생 386 | * 서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다. 387 | * `Access-Control-Allow-Origin: www.zerocho.com` 388 | * 프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다. 389 | * `Access-Control-Allow-Origin: *` 390 | * 만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다. 391 | * 유사한 헤더로 `Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers` 등이 있다. 392 | 393 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 394 | > - [http://www.ktword.co.kr/abbr_view.php?nav=&m_temp1=5905&id=902](http://www.ktword.co.kr/abbr_view.php?nav=&m_temp1=5905&id=902) 395 | > - [https://gmlwjd9405.github.io/2019/01/28/http-header-types.html](https://gmlwjd9405.github.io/2019/01/28/http-header-types.html) 396 | > - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers) 397 | 398 | ### HTTP와 HTTPS 동작 과정 399 | #### HTTP 동작 과정 400 | * 서버 접속 -> 클라이언트 -> 요청 -> 서버 -> 응답 -> 클라이언트 -> 연결 종료 401 | 1. **사용자가 웹 브라우저에 URL 주소 입력** 402 | 2. **DNS 서버에 웹 서버의 호스트 이름을 IP 주소로 변경 요청** 403 | 3. **웹 서버와 TCP 연결 시도** 404 | * 3way-handshaking 405 | 4. **클라이언트가 서버에게 요청** 406 | * HTTP Request Message = Request Header + 빈 줄 + Request Body 407 | * Request Header 408 | * 요청 메소드 + 요청 URI + HTTP 프로토콜 버전 409 | * ```GET /background.png HTTP/1.0``` ```POST / HTTP 1.1``` 410 | * Header 정보(key-value 구조) 411 | * 빈 줄 412 | * 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도 413 | * Request Body 414 | * GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 바디 미포함 415 | * 데이터 업데이트 요청과 관련된 내용 (HTML 폼 콘텐츠 등) 416 | 5. **서버가 클라이언트에게 데이터 응답** 417 | * HTTP Response Message = Response Header + 빈 줄 + Response Body 418 | * Response Header 419 | * HTTP 프로토콜 버전 + 응답 코드 + 응답 메시지 420 | * ex. ```HTTP/1.1 404 Not Found.``` 421 | * Header 정보(key-value 구조) 422 | * 빈 줄 423 | * 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도 424 | * Response Body 425 | * 응답 리소스 데이터 426 | * 201, 204 상태 코드는 바디 미포함 427 | 6. **서버 클라이언트 간 연결 종료** 428 | * 4way-handshaking 429 | 7. **웹 브라우저가 웹 문서 출력** 430 | 431 | #### HTTPS(SSL) 동작 과정 432 | * 공개키 암호화 방식과 대칭키 암호화 방식의 장점을 활용해 하이브리드 사용 433 | * 데이터를 대칭키 방식으로 암복호화하고, 공개키 방식으로 대칭키 전달 434 | 1. **클라이언트가 서버 접속하여 Handshaking 과정에서 서로 탐색** 435 | 436 | 1.1. **Client Hello** 437 | * 클라이언트가 서버에게 전송할 데이터 438 | * 클라이언트 측에서 생성한 **랜덤 데이터** 439 | * 클-서 암호화 방식 통일을 위해 **클라이언트가 사용할 수 있는 암호화 방식** 440 | * 이전에 이미 Handshaking 기록이 있다면 자원 절약을 위해 기존 세션을 재활용하기 위한 **세션 아이디** 441 | 442 | 1.2. **Server Hello** 443 | * Client Hello에 대한 응답으로 전송할 데이터 444 | * 서버 측에서 생성한 **랜덤 데이터** 445 | * **서버가 선택한 클라이언트의 암호화 방식** 446 | * **SSL 인증서** 447 | 448 | 1.3. **Client 인증 확인** 449 | * 서버로부터 받은 인증서가 CA에 의해 발급되었는지 본인이 가지고 있는 목록에서 확인하고, 목록에 있다면 CA 공개키로 인증서 복호화 450 | * 클-서 각각의 랜덤 데이터를 조합하여 pre master secret 값 생성(데이터 송수신 시 대칭키 암호화에 사용할 키) 451 | * pre master secret 값을 공개키 방식으로 서버 전달(공개키는 서버로부터 받은 인증서에 포함) 452 | * 일련의 과정을 거쳐 session key 생성 453 | 454 | 1.4. **Server 인증 확인** 455 | * 서버는 비공개키로 복호화하여 pre master secret 값 취득(대칭키 공유 완료) 456 | * 일련의 과정을 거쳐 session key 생성 457 | 458 | 1.5. **Handshaking 종료** 459 | 2. **데이터 전송** 460 | * 서버와 클라이언트는 session key를 활용해 데이터를 암복호화하여 데이터 송수신 461 | 3. **연결 종료 및 session key 폐기** 462 | 463 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#2-network) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 464 | > - [[Network] HTTP의 동작 및 HTTP Message 형식](https://gmlwjd9405.github.io/2019/04/17/what-is-http-protocol.html) 465 | > - [HTTP 동작 과정](https://jess-m.tistory.com/17) 466 | > - [HTTP 메시지](https://developer.mozilla.org/ko/docs/Web/HTTP/Messages) 467 | > - [HTTPS와 SSL 인증서](https://opentutorials.org/course/228/4894) 468 | 469 | ### CORS란 470 | - CORS(Cross Origin Resource Sharing)란 471 | - 웹 서버에게 보안 cross-domain 데이터 전송을 활성화하는 cross-domain 접근 제어권을 부여한다. 472 | - 배경 473 | - 처음 전송되는 리소스의 도메인과 다른 도메인으로부터 리소스가 요청될 경우 해당 리소스는 cross-origin HTTP 요청에 의해 요청된다. 474 | - 보안 상의 이유로, 브라우저들은 스크립트 내에서 초기화되는 cross-origin HTTP 요청을 제한한다. 475 | - 예를 들면, XMLHttpRequest는 same-origin 정책을 따르기에 XMLHttpRequest을 사용하는 웹 애플리케이션은 자신과 동일한 도메인으로 HTTP 요청을 보내는 것만 가능했다. 476 | - 웹 애플리케이션을 개선시키기 위해, 개발자들은 브라우저 벤더사들에게 XMLHttpRequest가 cross-domain 요청을 할 수 있도록 요청했고 이에 따라 CORS가 생겼다. 477 | - 과정 478 | - CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다. 479 | - 이때 Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고, 480 | - Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다. 481 | - Allow 항목들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다. 482 | - Request랑 Allow가 일치하면 CORS 요청이 이루어진다. 483 | 484 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 485 | > - [https://zamezzz.tistory.com/137](https://zamezzz.tistory.com/137) 486 | > - [https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS](https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS) 487 | 488 | ### GET 메서드와 POST 메서드 489 | * HTTP 프로토콜을 이용해서 서버에 데이터(요청 정보)를 전달할 때 사용하는 방식 490 | * GET 메서드 방식 491 | * 개념 492 | * 정보를 조회하기 위한 메서드 493 | * 서버에서 어떤 데이터를 가져와서 보여주기 위한 용도의 메서드 494 | * **가져오는 것(Select)** 495 | * 사용 방법 496 | * URL의 끝에 '?'가 붙고, 요청 정보가 (key=value)형태의 쌍을 이루어 ?뒤에 이어서 붙어 서버로 전송한다. 497 | * 요청 정보가 여러 개일 경우에는 '&'로 구분한다. 498 | * Ex) `www.urladdress.xyz?name1=value1&name2=value2` 499 | * 특징 500 | * URL에 요청 정보를 붙여서 전송한다. 501 | * URL에 요청 정보가 이어붙기 때문에 길이 제한이 있어서 대용량의 데이터를 전송하기 어렵다. 502 | * 한 번 요청 시 전송 데이터(주솟값 + 파라미터)의 양은 255자로 제한된다.(HTTP/1.1은 2048자) 503 | * 요청 정보를 사용자가 쉽게 눈으로 확인할 수 있다. 504 | * POST 방식보다 보안상 취약하다. 505 | * HTTP 패킷의 Body는 비어 있는 상태로 전송한다. 506 | * 즉, Body의 데이터 타입을 표현하는 'Content-Type' 필드도 HTTP Request Header에 들어가지 않는다. 507 | * POST 방식보다 빠르다. 508 | * GET 방식은 캐싱을 사용할 수 있어, GET 요청과 그에 대한 응답이 브라우저에 의해 캐쉬된다. 509 | * POST 메서드 방식 510 | * 개념 511 | * 서버의 값이나 상태를 바꾸기 위한 용도의 메서드 512 | * **수행하는 것(Insert, Update, Delete)** 513 | * 사용 방법 514 | * 요청 정보를 HTTP 패킷의 Body 안에 숨겨서 서버로 전송한다. 515 | 516 | * Request Header의 Content-Type에 해당 데이터 타입이 표현되며, 전송하고자 하는 데이터 타입을 적어주어야 한다. 517 | * Default: application/octet-stream 518 | * 단순 txt의 경우: text/plain 519 | * 파일의 경우: multipart/form-date 520 | * 특징 521 | * Body 안에 숨겨서 요청 정보를 전송하기 때문에 대용량의 데이터를 전송하기에 적합하다. 522 | * 클라이언트 쪽에서 데이터를 인코딩하여 서버로 전송하고, 이를 받은 서버 쪽이 해당 데이터를 디코딩한다. 523 | * GET 방식보다 보안상 안전하다. 524 | * Q. 조회하기 위한 용도 POST가 아닌 GET 방식을 사용하는 이유? 525 | 1. 설계 원칙에 따라 GET 방식은 서버에게 여러 번 요청을 하더라도 동일한 응답이 돌아와야 한다. (Idempotent, 멱등) 526 | * GET 방식은 **가져오는 것(Select)** 으로, 서버의 데이터나 상태를 변경시키지 않아야 한다. 527 | * Ex) 게시판의 리스트, 게시글 보기 기능 528 | * 예외) 방문자의 로그 남기기, 글을 읽은 횟수 증가 기능 529 | * POST 방식은 **수행하는 것** 으로, 서버의 값이나 상태를 바꾸기 위한 용도이다. 530 | * Ex) 게시판에 글쓰기 기능 531 | 2. 웹에서 모든 리소스는 Link할 수 있는 URL을 가지고 있어야 한다. 532 | * 어떤 웹페이지를 보고 있을 때 다른 사람한테 그 주소를 주기 위해서 주소창의 URL을 복사해서 줄 수 있어야 한다. 533 | * 즉, 어떤 웹페이지를 조회할 때 원하는 페이지로 바로 이동하거나 이동시키기 위해서는 해당 링크의 정보가 필요하다. 534 | * 이때 POST 방식을 사용할 경우에 값(링크의 정보)이 Body에 있기 때문에 URL만 전달할 수 없으므로 GET 방식을 사용해야한다. 그러나 글을 저장하는 경우에는 URL을 제공할 필요가 없기 때문에 POST 방식을 사용한다. 535 | 536 | 537 | 538 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 539 | > - [https://blog.outsider.ne.kr/312](https://blog.outsider.ne.kr/312) 540 | > - [https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/](https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/) 541 | > - [https://www.w3schools.com/tags/ref_httpmethods.asp](https://www.w3schools.com/tags/ref_httpmethods.asp) 542 | 543 | ### 쿠키와 세션 544 | * HTTP 프로토콜의 특징 545 | * 비연결 지향(Connectionless) 546 | * 클라이언트가 request를 서버에 보내고, 서버가 클라이언트에 요청에 맞는 response를 보내면 바로 연결을 끊는다. 547 | * 상태정보 유지 안 함(Stateless) 548 | * 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다. 549 | * 쿠키와 세션의 필요성 550 | * HTTP 프로토콜은 위와 같은 특징으로 모든 요청 간 의존관계가 없다. 551 | * 즉, 현재 접속한 사용자가 이전에 접속했던 사용자와 같은 사용자인지 아닌지 알 수 있는 방법이 없다. 552 | * 계속해서 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것이 큰 장점이지만, 통신할 때마다 새로 연결하기 때문에 클라이언트는 매 요청마다 인증을 해야 한다는 단점이 있다. 553 | * 이전 요청과 현재 요청이 같은 사용자의 요청인지 알기 위해서는 상태를 유지해야 한다. 554 | * HTTP 프로토콜에서 상태를 유지하기 위한 기술로 쿠키와 세션이 있다. 555 | * 쿠키(Cookie)란? 556 | * 개념 557 | * 클라이언트 로컬에 저장되는 키와 값이 들어있는 파일이다. 558 | * 이름, 값, 유효 시간, 경로 등을 포함하고 있다. 559 | * 클라이언트의 상태 정보를 브라우저에 저장하여 참조한다. 560 | * 구성 요소 561 | * 쿠키의 이름(name) 562 | * 쿠키의 값(value) 563 | * 쿠키의 만료시간(Expires) 564 | * 쿠키를 전송할 도메인 이름(Domain) 565 | * 쿠키를 전송할 경로(Path) 566 | * 보안 연결 여부(Secure) 567 | * HttpOnly 여부(HttpOnly) 568 | * 동작 방식 569 | 570 | 1. 웹브라우저가 서버에 요청 571 | 2. 상태를 유지하고 싶은 값을 쿠키(cookie)로 생성 572 | 3. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 쿠키를 포함해서 전송 573 | ```java 574 | Set−Cookie: id=doy 575 | ``` 576 | 4. 전달받은 쿠키는 웹브라우저에서 관리하고 있다가, 다음 요청 때 쿠키를 HTTP 헤더에 넣어서 전송 577 | ```java 578 | cookie: id=doy 579 | ``` 580 | 5. 서버에서는 쿠키 정보를 읽어 이전 상태 정보를 확인한 후 응답 581 | * 쿠키 사용 예 582 | * 아이디, 비밀번호 저장 583 | * 쇼핑몰 장바구니 584 | * 세션(Session)이란? 585 | * 개념 586 | * 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술이다. 587 | * 즉, 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태이다. 588 | * 동작 방식 589 | 590 | 1. 웹브라우저가 서버에 요청 591 | 2. 서버가 해당 웹브라우저(클라이언트)에 유일한 ID(Session ID)를 부여함 592 | 3. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 Session ID를 포함해서 전송 593 | 쿠키에 Session ID를 JSESSIONID 라는 이름으로 저장 594 | ```java 595 | Set−Cookie: JSESSIONID=xslei13f 596 | ``` 597 | 4. 웹브라우저는 이후 웹브라우저를 닫기까지 다음 요청 때 부여된 Session ID가 담겨있는 쿠키를 HTTP 헤더에 넣어서 전송 598 | ```java 599 | Cookie: JSESSIONID=xslei13f 600 | ``` 601 | 5. 서버는 세션 ID를 확인하고, 해당 세션에 관련된 정보를 확인한 후 응답 602 | * 세션 사용 예 603 | * 로그인 604 | > 세션도 쿠키를 사용하여 값을 주고받으며 클라이언트의 상태 정보를 유지한다. 605 | > 즉, 상태 정보를 유지하는 수단은 **쿠키** 이다. 606 | * 쿠키와 세션의 차이점 607 | * 저장 위치 608 | * 쿠키 : 클라이언트 609 | * 세션 : 서버 610 | * 보안 611 | * 쿠키 : 클라이언트에 저장되므로 보안에 취약하다. 612 | * 세션 : 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋다. 613 | * 라이프사이클 614 | * 쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다. 615 | * 세션 : 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다. 616 | * 속도 617 | * 쿠키 : 클라이언트에 저장되어서 서버에 요청 시 빠르다. 618 | * 세션 : 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느리다. 619 | 620 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 621 | > - [https://doooyeon.github.io/2018/09/10/cookie-and-session.html](https://doooyeon.github.io/2018/09/10/cookie-and-session.html) 622 | 623 | ### DNS 624 | 625 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 626 | > - []() 627 | 628 | ### REST와 RESTful의 개념 629 | * REST란 630 | * REST의 정의 631 | * "Representational State Transfer(대표적인 상태 전달)"의 약자 632 | * 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식 633 | * REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다. 634 | * REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다. 635 | * REST의 구체적인 개념 636 | * **HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.** 637 | * 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다. 638 | * 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다. 639 | * REST 장단점 640 | * 장점 641 | * 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해준다. 642 | * Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다. 643 | * HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다. 644 | * 단점 645 | * 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다. 646 | * 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다. 647 | * PUT, DELETE를 사용하지 못하는 점 648 | * pushState를 지원하지 않는 점 649 | * REST가 필요한 이유 650 | * '애플리케이션 분리 및 통합' 651 | * '다양한 클라이언트의 등장' 652 | * 즉, 최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다. 653 | * REST 구성 요소 654 | 1. 자원(Resource): URI 655 | * 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다. 656 | * 자원을 구별하는 ID는 '/groups/:group_id'와 같은 HTTP **URI** 다. 657 | * Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다. 658 | 2. 행위(Verb): HTTP Method 659 | * HTTP 프로토콜의 Method를 사용한다. 660 | * HTTP 프로토콜은 **GET, POST, PUT, DELETE, HEAD** 와 같은 메서드를 제공한다. 661 | 3. 표현(Representation of Resource) 662 | * Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다. 663 | * REST에서 하나의 자원은 **JSON, XML, TEXT, RSS** 등 여러 형태의 Representation으로 나타내어 질 수 있다. 664 | * JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다. 665 | * REST 특징 666 | 1. Server-Client(서버-클라이언트 구조) 667 | 2. Stateless(무상태) 668 | 3. Cacheable(캐시 처리 가능) 669 | 4. Layered System(계층화) 670 | 5. Code-On-Demand(optional) 671 | 6. Uniform Interface(인터페이스 일관성) 672 | * REST API 673 | * REST API의 정의 674 | * REST 기반으로 서비스 API를 구현한 것 675 | * 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다. 676 | * REST API의 특징 677 | * 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다. 678 | * REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다. 679 | * 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다. 680 | * REST API 설계 **기본 규칙** 681 | 1. URI는 정보의 자원을 표현해야 한다. 682 | * resource는 동사보다는 명사를 사용한다. 683 | * resource는 영어 소문자 복수형을 사용하여 표현한다. 684 | * Ex) `GET /Member/1` -> `GET /members/1` 685 | 2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다. 686 | * URI에 HTTP Method가 들어가면 안된다. 687 | * Ex) `GET /members/delete/1` -> `DELETE /members/1` 688 | * URI에 행위에 대한 동사 표현이 들어가면 안된다. 689 | * Ex) `GET /members/show/1` -> `GET /members/1` 690 | * Ex) `GET /members/insert/2` -> `POST /members/2` 691 | * REST API 설계 규칙 692 | 1. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다. 693 | * Ex) `http://restapi.example.com/houses/apartments` 694 | 2. URI 마지막 문자로 슬래시(/ )를 포함하지 않는다. 695 | * URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다. 696 | * REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다. 697 | * Ex) `http://restapi.example.com/houses/apartments/ (X)` 698 | 3. 하이픈(- )은 URI 가독성을 높이는데 사용 699 | * 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다. 700 | 4. 밑줄(_ )은 URI에 사용하지 않는다. 701 | * 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다. 702 | 5. URI 경로에는 소문자가 적합하다. 703 | * URI 경로에 대문자 사용은 피하도록 한다. 704 | * RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문 705 | 6. 파일확장자는 URI에 포함하지 않는다. 706 | * REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. 707 | * Accept header를 사용한다. 708 | * Ex) `http://restapi.example.com/members/soccer/345/photo.jpg (X)` 709 | * Ex) `GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)` 710 | 7. 리소스 간에는 연관 관계가 있는 경우 711 | * /리소스명/리소스 ID/관계가 있는 다른 리소스명 712 | * Ex) `GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)` 713 | 8. :id는 하나의 특정 resource를 나타내는 고유값 714 | * Ex) student를 생성하는 route: POST /students 715 | * Ex) id=12인 student를 삭제하는 route: DELETE /students/12 716 | * RESTful 717 | * RESTful의 개념 718 | * RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다. 719 | * 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다. 720 | * RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다. 721 | * RESTful의 목적 722 | * 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것 723 | * RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기이니, 퍼포먼스가 중요한 상황에서는 굳이 RESTful API를 구현하실 필요는 없습니다. 724 | * RESTful 하지 못한 경우 725 | * Ex1) CRUD 기능을 모두 POST로만 처리하는 API 726 | * Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName) 727 | 728 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 729 | > - [https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html](https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html) 730 | > - [https://www.a-mean-blog.com/ko/blog/%ED%86%A0%EB%A7%89%EA%B8%80/_/REST%EC%99%80-RESTful-API](https://www.a-mean-blog.com/ko/blog/%ED%86%A0%EB%A7%89%EA%B8%80/_/REST%EC%99%80-RESTful-API) 731 | > - [http://mygumi.tistory.com/55](http://mygumi.tistory.com/55) 732 | > - [https://brainbackdoor.tistory.com/53](https://brainbackdoor.tistory.com/53) 733 | > - [http://tech.devgear.co.kr/delphi_news/433404](http://tech.devgear.co.kr/delphi_news/433404) 734 | > - [https://meetup.toast.com/posts/92](https://meetup.toast.com/posts/92) 735 | > - [https://spoqa.github.io/2012/02/27/rest-introduction.html](https://spoqa.github.io/2012/02/27/rest-introduction.html) 736 | 737 | ### 소켓이란 738 | 739 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 740 | > - []() 741 | 742 | ### Socket.io와 WebSocket의 차이 743 | * WebSocket 744 | * 개념 745 | * 웹 페이지의 한계에서 벗어나 실시간으로 상호작용하는 웹 서비스를 만드는 표준 기술 746 | * 배경 747 | * HTTP 프로토콜은 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 방법이다. 748 | * 실시간 웹을 구현하기 위해서는 양방향 통신이 가능해야 하는데, WebSocket 이전에는 Polling, Streaming 방식의 AJAX 코드를 이용하여 이를 구현하였다. 749 | * 하지만 이 방법들을 이용하면 각 브라우저마다 구현 방법이 달라 개발이 어렵다는 문제점이 있었다. 750 | * 이를 위해 HTML5 표준의 일부로 WebSocket이 만들어지게 되었다. 751 | * 일반 TCP Socket과의 차이점 752 | * 일반 HTTP Request를 통해 handshaking 과정을 거쳐 최초 접속이 이루어진다. 753 | * 특징 754 | * 소켓을 이용하여 자유롭게 데이터를 주고 받을 수 있다. 755 | * 기존의 요청-응답 관계 방식보다 더 쉽게 데이터를 교환할 수 있다. 756 | * 다른 HTTP Request와 마찬가지로 80포트를 통해 웹 서버에 연결한다. 757 | * http:// 대신 ws:// 로 시작하며 Streaming과 유사한 방식으로 푸쉬를 지원한다. 758 | * 클라이언트인 브라우저와 마찬가지로 웹 서버도 WebSocket 기능을 지원해야 한다. (WebSocket을 지원하는 여러 서버 구현체(Jetty, GlassFish, Node.js, Netty, Grizzly 등)가 있다.) 759 | * 클라이언트인 브라우저 중에서는 Chrome, Safari, Firefox, Opera에서 WebSocket을 사용할 수 있으며, 각종 모바일 브라우저에서도 WebSocket을 사용할 수 있다. 760 | * WebSocket 프로토콜은 아직 확정된 상태가 아니기 때문에 브라우저별로 지원하는 WebSocket 버전이 다르다. (예전 브라우저는 지원하지 않는다.) 761 | * 즉, WebSocket은 다가올 미래의 기술이지 아직 인터넷 기업에서 시범적으로라도 써 볼 수 있는 기술이 아니다. 762 | * 장점 763 | * HTTP Request를 그대로 사용하기 때문에 기존의 80, 443포트로 접속을 하므로 추가로 방화벽을 열지 않고도 양방향 통신이 가능하다. 764 | * HTTP 규격인 CORS 적용이나 인증 등의 과정을 기존과 동일하게 사용할 수 있다. 765 | * Socket.io 766 | * 개념 767 | * 다양한 방식의 실시간 웹 기술을 손쉽게 사용할 수 있는 모듈 (웹 클라이언트로의 푸쉬를 지원하는 모듈) 768 | * WebSocket, FlashSocket, AJAX Long Polling, AJAX Multi part Streaming, IFrame, JSONP Polling 등 다양한 방법을 하나의 API로 추상화한 것이다. 769 | * 즉, Socket.io는 JavaScript를 이용하여 브라우저 종류에 상관없이 실시간 웹을 구현할 수 있도록 한 기술이다. 770 | * 특징 771 | * Socket.io는 현재 바로 사용할 수 있는 기술이다. 772 | * WebSocket 프로토콜은 IETF에서 관장하는 표준 프로토콜이라서 WebSocket을 지원하는 여러 서버 구현체(Jetty, GlassFish, Node.js, Netty, Grizzly 등)가 있지만 Socket.io는 Node.js 하나 밖에 없다. 773 | * 장점 774 | * 개발자는 Socket.io로 개발을 하고 클라이언트로 푸쉬 메시지를 보내기만 하면, WebSocket을 지원하지 않는 브라우저의 경우는 브라우저 모델과 버전에 따라서 AJAX Long Polling, MultiPart Streaming, Iframe을 이용한 푸쉬, JSONP Polling, Flash Socket 등 다양한 방법으로 내부적으로 푸쉬 메시지를 보내준다. 775 | * 즉, WebSocket을 지원하지 않는 어느 브라우져라도 푸쉬 메시지를 일관된 모듈로 보낼 수 있다. 776 | 777 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 778 | > - [https://d2.naver.com/helloworld/1336](https://d2.naver.com/helloworld/1336) 779 | > - [http://bcho.tistory.com/896](http://bcho.tistory.com/896) 780 | > - [http://adrenal.tistory.com/20](http://adrenal.tistory.com/20) 781 | > - [http://blog.jeonghwan.net/socket-io를-이용한-실시간-웹-구현](http://blog.jeonghwan.net/socket-io%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%9B%B9-%EA%B5%AC%ED%98%84/) 782 | > - [http://woowabros.github.io/woowabros/2017/09/12/realtime-service.html](http://woowabros.github.io/woowabros/2017/09/12/realtime-service.html) 783 | 784 | 785 | ### Frame Packet Segment Datagram 786 | 787 | #### PDU (Protocol Data Unit) 788 | ![](./images/osi-pdu.png) 789 | 790 | 프로토콜 데이터 단위. 데이터 통신에서 상위 계층이 전달한 데이터에 붙이는 제어정보를 뜻한다. 각 계층의 데이터의 단위이다. 791 | - 물리 계층: Bit 792 | - 데이터링크 계층: Frame 793 | - 네트워크 계층: Packets 794 | - 전송 계층: Segment 795 | - 세션, 표현, 어플리케이션 계층: Message(Data) 796 | 797 | #### 데이터 캡슐화 798 | ![](./images/data-encapsulation.png) 799 | 800 | PDU는 SDU(Service Data Unit) 와 PCI(Protocol Control Information)로 구성되어 있다. SDU는 전송하려는 데이터고, PCI는 제어 정보다. PCI에는 송신자와 수신자 주소, 오류 검출 코드, 프로토콜 제어 정보 등이 있다. 데이터에 제어 정보를 덧붙이는 것을 캡슐화(Encapsulation)라 한다. 801 | 802 | 다시 말해, 캡슐화는 어떤 네트워크를 통과하기 위해 전송하려는 데이터를 다른 무언가로 감싸서 보내고 해당 네트워크를 통과하면 감싼 부분을 다시 벗겨내어 전송하는 기능을 말한다. 803 | 804 | 805 | 806 | 807 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/Do-Hee/tech-interview#2-network) :information_source:[Home](https://github.com/Do-Hee/tech-interview#tech-interview) 808 | > - []() 809 | 810 | --- 811 | ## Reference 812 | > - [데이터가 전달되는 원리" OSI 7계층 모델과 TCP/IP 모델](https://velog.io/@hidaehyunlee/%EB%8D%B0%EC%9D%B4%ED%84%B0%EA%B0%80-%EC%A0%84%EB%8B%AC%EB%90%98%EB%8A%94-%EC%9B%90%EB%A6%AC-OSI-7%EA%B3%84%EC%B8%B5-%EB%AA%A8%EB%8D%B8%EA%B3%BC-TCPIP-%EB%AA%A8%EB%8D%B8) 813 | > - [Network Fundamentals CCNA Exploration Companion Guide](https://www.ibserveis.com/pax/1-protocols_ok.pdf) 814 | > - [OSI 7계층](https://brownbears.tistory.com/189) 815 | > 816 | 817 | 818 | 819 | ## :house: [Home](https://github.com/Do-Hee/tech-interview) 820 | 821 | -------------------------------------------------------------------------------- /contents/os.md: -------------------------------------------------------------------------------- 1 | # 3. Operating System 2 | **:book: Contents** 3 | * [프로세스와 스레드의 차이(Process vs Thread)](#프로세스와-스레드의-차이) 4 | * [멀티 프로세스 대신 멀티 스레드를 사용하는 이유](#멀티-프로세스-대신-멀티-스레드를-사용하는-이유) 5 | * [Thread-safe](#thread-safe) 6 | * [동기화 객체의 종류](#동기화-객체의-종류) 7 | * [뮤텍스와 세마포어의 차이](#뮤텍스와-세마포어의-차이) 8 | * [스케줄러](#스케줄러) 9 | * [동기와 비동기](#동기와-비동기) 10 | * [프로세스 동기화](#프로세스-동기화) 11 | * [메모리 관리 전략](#메모리-관리-전략) 12 | * [가상 메모리](#가상-메모리) 13 | * [캐시의 지역성](#캐시의-지역성) 14 | * [교착상태(데드락, Deadlock)의 개념과 조건](#교착상태의-개념과-조건) 15 | * [사용자 수준 스레드와 커널 수준 스레드](#사용자-수준-스레드,-커널-수준-스레드) 16 | * [외부 단편화와 내부 단편화](#외부-단편화와-내부-단편화) 17 | * [Context Switching](#context-switching) 18 | * [Swapping](#swapping) 19 | 20 | --- 21 | 22 | ### 프로세스와 스레드의 차이 23 | * 프로그램(Program) 이란 24 | * 사전적 의미: 어떤 작업을 위해 실행할 수 있는 파일 25 | * 프로세스(Process) 란 26 | * 사전적 의미: 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램 27 | * 메모리에 올라와 **실행되고 있는 프로그램의 인스턴스(독립적인 개체)** 28 | * 운영체제로부터 시스템 자원을 할당받는 작업의 단위 29 | * 즉, 동적인 개념으로는 실행된 프로그램을 의미한다. 30 | * 할당받는 시스템 자원의 예 31 | * CPU 시간 32 | * 운영되기 위해 필요한 주소 공간 33 | * Code, Data, Stack, Heap의 구조로 되어 있는 독립된 메모리 영역 34 | * 특징 35 | * 36 | * 프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받는다. 37 | * 기본적으로 프로세스당 최소 1개의 스레드(메인 스레드)를 가지고 있다. 38 | * 각 프로세스는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없다. 39 | * 한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(IPC, inter-process communication)을 사용해야 한다. (Ex. 파이프, 파일, 소켓 등을 이용한 통신 방법 이용) 40 | * 스레드(Thread) 란 41 | * 사전적 의미: 프로세스 내에서 실행되는 여러 흐름의 단위 42 | * **프로세스의 특정한 수행 경로** 43 | * 프로세스가 할당받은 자원을 이용하는 실행의 단위 44 | * 특징 45 | * 46 | * 스레드는 프로세스 내에서 각각 Stack만 따로 할당받고 Code, Data, Heap 영역은 공유한다. 47 | * 스레드는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내의 주소 공간이나 자원들(힙 공간 등)을 같은 프로세스 내에 스레드끼리 공유하면서 실행된다. 48 | * 같은 프로세스 안에 있는 여러 스레드들은 같은 힙 공간을 공유한다. 반면에 프로세스는 다른 프로세스의 메모리에 직접 접근할 수 없다. 49 | * 각각의 스레드는 별도의 레지스터와 스택을 갖고 있지만, 힙 메모리는 서로 읽고 쓸 수 있다. 50 | * 한 스레드가 프로세스 자원을 변경하면, 다른 이웃 스레드(sibling thread)도 그 변경 결과를 즉시 볼 수 있다. 51 | * 자바 스레드(Java Thread) 란 52 | * 일반 스레드와 거의 차이가 없으며, JVM가 운영체제의 역할을 한다. 53 | * 자바에는 프로세스가 존재하지 않고 스레드만 존재하며, 자바 스레드는 JVM에 의해 스케줄되는 실행 단위 코드 블록이다. 54 | * 자바에서 스레드 스케줄링은 전적으로 JVM에 의해 이루어진다. 55 | * 아래와 같은 스레드와 관련된 많은 정보들도 JVM이 관리한다. 56 | * 스레드가 몇 개 존재하는지 57 | * 스레드로 실행되는 프로그램 코드의 메모리 위치는 어디인지 58 | * 스레드의 상태는 무엇인지 59 | * 스레드 우선순위는 얼마인지 60 | * 즉, 개발자는 자바 스레드로 작동할 스레드 코드를 작성하고, 스레드 코드가 생명을 가지고 실행을 시작하도록 JVM에 요청하는 일 뿐이다. 61 | 62 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 63 | > - [https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html](https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html) 64 | > - [https://brunch.co.kr/@kd4/3](https://brunch.co.kr/@kd4/3) 65 | > - [https://magi82.github.io/process-thread/](https://magi82.github.io/process-thread/) 66 | > - [https://jaybdev.net/2017/06/05/Java-3/](https://jaybdev.net/2017/06/05/Java-3/) 67 | > - [http://includestdio.tistory.com/6](http://includestdio.tistory.com/6) 68 | > - [https://lalwr.blogspot.com/2016/02/process-thread.html](https://lalwr.blogspot.com/2016/02/process-thread.html) 69 | 70 | ### 멀티 프로세스 대신 멀티 스레드를 사용하는 이유 71 | * 쉽게 설명하면, 프로그램을 여러 개 키는 것보다 하나의 프로그램 안에서 여러 작업을 해결하는 것이다. 72 | * 73 | 74 | 1. 자원의 효율성 증대 75 | * 멀티 프로세스로 실행되는 작업을 멀티 스레드로 실행할 경우, **프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어들어** 자원을 효율적으로 관리할 수 있다. 76 | * 프로세스 간의 Context Switching시 단순히 CPU 레지스터 교체 뿐만 아니라 RAM과 CPU 사이의 캐시 메모리에 대한 데이터까지 초기화되므로 오버헤드가 크기 때문 77 | * 스레드는 프로세스 내의 메모리를 공유하기 때문에 독립적인 프로세스와 달리 스레드 간 데이터를 주고 받는 것이 간단해지고 시스템 자원 소모가 줄어들게 된다. 78 | 2. 처리 비용 감소 및 응답 시간 단축 79 | * 또한 프로세스 간의 통신(IPC)보다 스레드 간의 통신의 비용이 적으므로 작업들 간의 통신의 부담이 줄어든다. 80 | * 스레드는 Stack 영역을 제외한 모든 메모리를 공유하기 때문 81 | * 프로세스 간의 전환 속도보다 스레드 간의 전환 속도가 빠르다. 82 | * Context Switching시 스레드는 Stack 영역만 처리하기 때문 83 | 84 | * ***주의할 점!*** 85 | * **동기화 문제** 86 | * 스레드 간의 자원 공유는 전역 변수(데이터 세그먼트)를 이용하므로 함께 상용할 때 충돌이 발생할 수 있다. 87 | 88 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 89 | > - [http://you9010.tistory.com/136](http://you9010.tistory.com/136) 90 | 91 | ### Thread-safe 92 | - **Thread-safe란?** 93 | - 직역하면 **스레드 안전**. 94 | - 멀티스레드 환경에서 여러 스레드가 동시에 하나의 객체 및 변수(공유 자원)에 접근할 때, 의도한 대로 동작하는 것을 말한다. 95 | - 이러한 상황을 "Thead-safe하다" 라고 표현한다. 96 | - **Thread-safe하게 구현하기** 97 | - Thread-safe하기 위해서는 공유 자원에 접근하는 임계영역(critical section)을 동기화 기법으로 제어해줘야 한다. 98 | - 이를 '상호배제'라고 한다. 99 | - 동기화 기법으로는 Mutex나 Semaphore 등이 있다. 100 | - **Reentrant** 101 | - Reentrant는 **재진입성**이라는 의미로, 어떤 함수가 Reentrant하다는 것은 여러 스레드가 동시에 접근해도 언제나 같은 실행 결과를 보장한다는 의미이다. 102 | - 이를 만족하기 위해서 해당 서브루틴에서는 공유자원을 사용하지 않으면 된다. 103 | - 예를들어 정적(전역) 변수를 사용하거나 반환하면 안 되고 호출 시 제공된 매개변수만으로 동작해야한다. 104 | - 따라서, Reentrant하다면 Thread-safe하지만 그 역은 성립하지 않는다. 105 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 106 | 107 | > - [위키백과 - 재진입성](https://ko.wikipedia.org/wiki/%EC%9E%AC%EC%A7%84%EC%9E%85%EC%84%B1) 108 | > - [[OS] Thread Safe란? - 곰팡](gompangs.tistory.com/7) 109 | > - [스레드-안전(Thread-safe)과 재진입가능(Reentrant)의 차이 - 커피한잔의 여유와 코딩](sjava.net/tag/thread-safe/) 110 | 111 | ### 동기화 객체의 종류 112 | * 스레드 동기화 방법 113 | 1. 실행 순서의 동기화 114 | * 스레드의 실행순서를 정의하고, 이 순서에 반드시 따르도록 하는 것 115 | 2. 메모리 접근에 대한 동기화 116 | * 메모리 접근에 있어서 동시접근을 막는 것 117 | * 실행의 순서가 중요한 상황이 아니고, 한 순간에 하나의 스레드만 접근하면 되는 상황을 의미 118 | * 동기화 기법의 종류 119 | 1. 유저 모드 동기화 120 | * 커널의 힘을 빌리지 않는(커널 코드가 실행되지 않는) 동기화 기법 121 | * 성능상 이점, 기능상의 제한 122 | * **Ex) 크리티컬 섹션 기반의 동기화, 인터락 함수 기반의 동기화** 123 | 2. 커널 모드 동기화 124 | * 커널에서 제공하는 동기화 기능을 활용하는 방법 125 | * 커널 모드로의 변경이 필요하고 이는 성능 저하로 이어짐, 다양한 기능 활용 가능 126 | * **Ex) 뮤텍스 기반의 동기화, 세마포어 기반의 동기화, 이름있는 뮤텍스 기반의 프로세스 동기화, 이벤트 기반의 동기화** 127 | 128 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 129 | > - [http://christin2.tistory.com/entry/Chapter-13-%EC%93%B0%EB%A0%88%EB%93%9C-%EB%8F%99%EA%B8%B0%ED%99%94-%EA%B8%B0%EB%B2%95-1](http://christin2.tistory.com/entry/Chapter-13-%EC%93%B0%EB%A0%88%EB%93%9C-%EB%8F%99%EA%B8%B0%ED%99%94-%EA%B8%B0%EB%B2%95-1) 130 | > - [https://m.blog.naver.com/PostView.nhn?blogId=smuoon4680&logNo=50127179815&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F](https://m.blog.naver.com/PostView.nhn?blogId=smuoon4680&logNo=50127179815&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F) 131 | 132 | ### 뮤텍스와 세마포어의 차이 133 | * 뮤텍스(Mutex) 134 | * 공유된 자원의 데이터를 **여러 스레드가** 접근하는 것을 막는 것 135 | * 상호배제라고도 하며, Critical Section을 가진 스레드의 Running time이 서로 겹치지 않도록 각각 단독으로 실행하게 하는 기술이다. 136 | * 다중 프로세스들의 공유 리소스에 대한 접근을 조율하기 위해 synchronized 또는 lock을 사용한다. 137 | * 즉, 뮤텍스 객체를 두 스레드가 동시에 사용할 수 없다. 138 | * 세마포어(Semaphore) 139 | * 공유된 자원의 데이터를 **여러 프로세스가** 접근하는 것을 막는 것 140 | * 리소스 상태를 나타내는 간단한 카운터로 생각할 수 있다. 141 | * 운영체제 또는 커널의 한 지정된 저장장치 내의 값이다. 142 | * 일반적으로 비교적 긴 시간을 확보하는 리소스에 대해 이용한다. 143 | * 유닉스 시스템 프로그래밍에서 세마포어는 운영체제의 리소스를 경쟁적으로 사용하는 다중 프로세스에서 행동을 조정하거나 또는 동기화 시키는 기술이다. 144 | * 공유 리소스에 접근할 수 있는 프로세스의 최대 허용치만큼 동시에 사용자가 접근하여 사용할 수 있다. 145 | * 각 프로세스는 세마포어 값은 확인하고 변경할 수 있다. 146 | * 1) 사용 중이지 않는 자원의 경우 그 프로세스가 즉시 자원을 사용할 수 있다. 147 | * 2) 이미 다른 프로세스에 의해 사용 중이라는 사실을 알게 되면 재시도하기 전에 일정 시간을 기다려야 한다. 148 | * 세마포어를 사용하는 프로세스는 그 값을 확인하고, 자원을 사용하는 동안에는 그 값을 변경함으로써 다른 세마포어 사용자들이 기다리도록 해야한다. 149 | * 세마포어는 이진수 (0 또는 1)를 사용하거나, 또는 추가적인 값을 가질 수도 있다. 150 | * 차이 151 | 1. 가장 큰 차이점은 관리하는 **동기화 대상의 개수** 152 | * Mutex는 동기화 대상이 오직 하나뿐일 때, Semaphore는 동기화 대상이 하나 이상일 때 사용한다. 153 | 2. Semaphore는 Mutex가 될 수 있지만 Mutex는 Semaphore가 될 수 없다. 154 | * Mutex는 상태가 0, 1 두 개 뿐인 binary Semaphore 155 | 3. Semaphore는 소유할 수 없는 반면, Mutex는 소유가 가능하며 소유주가 이에 대한 책임을 가진다. 156 | * Mutex 의 경우 상태가 두개 뿐인 lock 이므로 lock 을 가질 수 있다. 157 | 4. Mutex의 경우 Mutex를 소유하고 있는 스레드가 이 Mutex를 해제할 수 있다. 하지만 Semaphore의 경우 이러한 Semaphore를 소유하지 않는 스레드가 Semaphore를 해제할 수 있다. 158 | 5. Semaphore는 시스템 범위에 걸쳐있고 파일시스템상의 파일 형태로 존재하는 반면 Mutex는 프로세스 범위를 가지며 프로세스가 종료될 때 자동으로 Clean up 된다. 159 | 160 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 161 | > - [http://jwprogramming.tistory.com/13](http://jwprogramming.tistory.com/13) 162 | 163 | ### 스케줄러 164 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 165 | > - []() 166 | 167 | ### 동기와 비동기 168 | 이 개념은 OS에서 뿐만 아니라 여러가지 분야에서도 쓰인다. 169 | - **동기(Synchronous)란?** 170 | > '동기' 라고하면 다수의 개채들이 동일(일정)한 **무언가**를 가지는 것. 또는 **무언가**가 동일(일정)하게 되는 것. 171 | - 그 **무언가**는 `상태`가 될 수 있고 `행위`가 될 수 있고, `시간`,`속도`, `주기`, `출현` 등이 될 수 있다. 172 | - 여기서 말하는 '동기'는 두개의 프로세스가 데이터를 주고 받을 때, 주고 받는 `순서`(또는 `시간`)가 일정하다는 것을 뜻한다. (너 한번, 나 한번) 173 | - **비동기(Asynchronous)란?** 174 | - '동기'가 아닌 것. 175 | - **동기식, 동기적이다.** 176 | - 어떤 작업을 요청했을 때 그 작업이 종료될 때까지 기다린 후 다음 작업을 수행한다. 177 | - 데이터를 주고받는 '순서'가 중요할때 사용된다. 178 | - 요청한 작업만 처리하면 되기 때문에 전체적인 수행 속도는 빠를 수 있다. (일만 하면 된다) 179 | - 한 작업에 대한 시간이 길어질 경우, 전체 응답이 지연될 수 있다. 180 | - **비동기식, 비동기적이다.** 181 | - 어떤 작업을 요청했을 때 그 작업이 종료될 때까지 기다리지 않고(작업을 위임하고), 다음 작업을 수행한다. 요청했던 작업이 끝나면 결과를 받고, 그에 따른 추가 작업이 있다면 수행한다. 182 | - 요청 순서에 상관없이, 동시에 다수의 작업을 처리할 수 있다. 183 | - 작업이 끝날 때 따로 이벤트를 감지하고 결과를 받아 그에 따른 추가 작업을 해줘야하기 때문에, 비교적 느릴 수 있다. 184 | - I/O 작업이 잦고, 빠른 응답속도를 요구하는 프로그램에 적합하다. 185 | 186 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 187 | > - [동기(Sync) 와 비동기(Async) - 리충닷컴](http://leechoong.com/posts/2017/nodejs_syncasync/) 188 | > - [Sync async-blocking-nonblocking-io - Choloh Bae](https://www.slideshare.net/unitimes/sync-asyncblockingnonblockingio) 189 | > - [Synchronous(동기) Vs Asynchronous(비동기) - Nesoy Bolg](https://nesoy.github.io/articles/2017-01/Synchronized) 190 | 191 | ### 프로세스 동기화 192 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 193 | > - []() 194 | 195 | ### 메모리 관리 전략 196 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 197 | > - []() 198 | 199 | ### 가상 메모리 200 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 201 | > - []() 202 | 203 | ### 캐시의 지역성 204 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 205 | > - []() 206 | 207 | ### 교착상태의 개념과 조건 208 | * 교착상태(데드락, Deadlock) 란 209 | * 첫 번째 스레드는 두 번째 스레드가 들고 있는 객체의 락이 풀리기를 기다리고 있고, 두 번째 스레드 역시 첫 번째 스레드가 들고 있는 객체의 락이 풀리기를 기다리는 상황을 일컷는다. 210 | * 모든 스레드가 락이 풀리기를 기다리고 있기 때문에, 무한 대기 상태에 빠지게 된다. 이런 스레드를 교착상태에 빠졌다고 한다. 211 | * 교착상태의 4가지 조건 212 | 1. 상호 배제(mutual exclusion) 213 | * 한 번에 한 프로세스만 공유 자원을 사용할 수 있다. 214 | * 좀 더 정확하게는, 공유 자원에 대한 접근 권한이 제한된다. 자원의 양이 제한되어 있더라도 교착상태는 발생할 수 있다. 215 | 2. 들고 기다리기(hold and wait) = **점유대기** 216 | * 공유 자원에 대한 접근 권한을 갖고 있는 프로세스가, 그 접근 권한을 양보하지 않은 상태에서 다른 자원에 대한 접근 권한을 요구할 수 있다. 217 | 3. 선취(preemption) 불가능 = **비선점** 218 | * 한 프로세스가 다른 프로세스의 자원 접근 권한을 강제로 취소할 수 없다. 219 | 4. 대기 상태의 사이클(circular wait) = **순환대기** 220 | * 두 개 이상의 프로세스가 자원 접근을 기다리는데, 그 관계에 사이클이 존재한다. 221 | * 교착상태 방지 222 | * 4가지 조건들 가운데 하나를 제거하면 된다. 223 | * 공유 자원 중 많은 경우가 한 번에 한 프로세스만 사용할 수 있기 때문에(예를 들어, 프린트) 1번 조건은 제거하기 어렵다. 224 | * 대부분의 교착상태 방지 알고리즘은 4번 조건, 즉 대기 상태의 사이클이 발생하는 일을 막는 데 초점이 맞춰져 있다. 225 | 226 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 227 | > - [코딩 인터뷰 완전 분석, 프로그래밍인사이트](https://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788966263080&OV_REFFER=http://click.linkprice.com/click.php?m=kbbook&a=A100532541&l=9999&l_cd1=0&u_id=jm0gctc7ca029ofs02yqe&l_cd2=0&tu=https%3A%2F%2Fwww.kyobobook.co.kr%2Fproduct%2FdetailViewKor.laf%3FmallGb%3DKOR%26ejkGb%3DKOR%26barcode%3D9788966263080) 228 | 229 | ### 사용자 수준 스레드와 커널 수준 스레드 230 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 231 | > - []() 232 | 233 | ### 외부 단편화와 내부 단편화 234 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 235 | > - []() 236 | 237 | ### Context Switching 238 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 239 | 240 | * Context Switching이란? 241 | * 현재 진행하고 있는 Task(Process, Thread)의 상태를 저장하고 다음 진행할 Task의 상태 값을 읽어 적용하는 과정을 말한다. 242 | * Context Switching 과정 243 | 1. Task의 대부분 정보는 Register에 저장되고 PCB(Process Control Block)로 관리된다. 244 | 2. 현재 실행하고 있는 Task의 PCB 정보를 저장한다. (Process Stack, Ready Queue) 245 | 3. 다음 실행할 Task의 PCB 정보를 읽어 Register에 적재하고 CPU가 이전에 진행했던 과정을 연속적으로 수행할 수 있다. 246 | * Context Switching Cost (Process vs Thread) 247 | * Process Context Switching 비용 > Thread Context Switching 비용 248 | * Thread는 Stack 영역을 제외한 모든 메모리를 공유하므로 Context Switching 수행 시 Stack 영역만 변경하면 되기 때문에 비용이 적게 든다. 249 | 250 | > - [Context Switching이란?](https://nesoy.github.io/articles/2018-11/Context-Switching) 251 | 252 | ### Swapping 253 | > :arrow_double_up:[Top](#3-operating-system) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#3-operating-system) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 254 | > - []() 255 | 256 | --- 257 | 258 | ## Reference 259 | > - []() 260 | 261 | 262 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 263 | -------------------------------------------------------------------------------- /contents/security.md: -------------------------------------------------------------------------------- 1 | # 9. Security 2 | **:book: Contents** 3 | 4 | - [대칭키와 비대칭키 차이](#대칭키와-비대칭키-차이) 5 | - [패스워드 암호화 방법](#패스워드-암호화-방법) 6 | - [SQL Injection 공격](#sql-injection-공격) 7 | - [CSRF 공격](#csrf-공격) 8 | - [XSS 공격](#xss-공격) 9 | - [OAuth](#oauth) 10 | 11 | --- 12 | 13 | ### 대칭키와 비대칭키 차이 14 | 1. 대칭키 암호화 방식 (비밀키 암호화 방식) 15 | - 개념 16 | - 하나의 비밀키를 이용한 암호화 방식 17 | 2. 비대칭키 암호화 방식 (공개키 암호화 방식) 18 | - 개념 19 | - 공개키(public)와 개인키(private)를 이용한 암호화 방식 20 | - 종류 21 | 1. 공개키로 암호화 22 | - 암호로서 효용성 23 | 2. 개인키로 암호화 24 | - 공인인증체계에 사용하는 전자서명법 25 | 26 | 28 | 33 | 34 | > :arrow_double_up:[Top](#9-security) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-security) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 35 | > - [http://blog.naver.com/PostView.nhn?blogId=mr100do&logNo=60144936458](http://blog.naver.com/PostView.nhn?blogId=mr100do&logNo=60144936458) 36 | > - [http://cryptocat.tistory.com/3](http://cryptocat.tistory.com/3) 37 | 38 | ### 패스워드 암호화 방법 39 | 1. 단순 텍스트(plain text) 40 | 2. 단방향 해시 함수(one-way hash function)의 다이제스트(digest) 41 | * 수학적인 연산을 통해 원본 메시지를 변환하여 암호화된 메시지인 다이제스트를 생성한다. 42 | * 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 '단방향성'이라고 한다. 43 | * 패스워드가 "hunter2"라면 이 문자열을 흔히 사용하는 해시 알고리즘인 "SHA-256"으로 인코딩 44 | * avalanche 효과 45 | * 대부분의 해시 함수는 입력 값의 일부가 변경되었을 때 다이제스트가 완전히 달라지도록 설계되어 있다. 46 | * "hunter3"라는 값의 SHA-256 다이제스트는 아래와 같으며 위의 "hunter2"와는 완전히 달라진 것을 확인할 수 있다. 47 | * 단방향 해시 함수의 문제점 48 | * 1. 인식 가능성(recognizability) 49 | * "레인보우 공격(rainbow attack)" 50 | * 공격자가 전처리(pre-computing)된 다이제스트를 가능한 한 많이 확보한 다음 이를 탈취한 다이제스트와 비교해 원본 메시지를 찾아내거나 동일한 효과의 메시지를 찾을 수 있다. 51 | * 2. 속도(speed) 52 | * 해시 함수는 짧은 시간에 데이터를 검색하기 위해 설계된 것 53 | * 해시 함수의 빠른 처리 속도로 인해 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다 54 | 3. 솔팅(salting) 55 | * 솔트(salt) 56 | * 단방향 해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열 57 | * 솔팅(salting) 58 | * 이 원본 메시지에 문자열을 추가하여 다이제스트를 생성하는 것 59 | * 솔트 + 원본 메시지(패스워드) = 다이제스트 60 | * 사용자별로 다른 솔트를 사용한다면 동일한 패스워드를 사용하는 사용자의 다이제스트가 다르게 생성되어 인식 가능성 문제가 크게 개선된다. 61 | * 솔트와 패스워드의 다이제스트를 데이터베이스에 저장하고, 사용자가 로그인할 때 입력한 패스워드를 해시하여 일치 여부를 확인할 수 있다. 62 | * 이 방법을 사용할 때에는 모든 패스워드가 고유의 솔트를 갖고 솔트의 길이는 32바이트 이상이어야 솔트와 다이제스트를 추측하기 어렵다. 63 | 4. 키 스트레칭(key stretching) 64 | * 여러 단계의 해시 함수를 적용하여 다이제스트를 생성하는 과정 65 | * 잘 설계된 패스워드 저장 시스템에서는 하나의 다이제스트를 생성할 때 어느 정도(일반적인 장비에서 0.2초 이상)의 시간이 소요되게 설정한다. 66 | * "억지 기법 공격(brute-force attack)"으로 패스워드를 추측하는 데 많은 시간이 소요되도록 하기 위한 것 67 | * 솔팅과 키 스트레칭으로 구성된 암호화 시스템을 구현하려고 한다면 이미 검증된 암호화 시스템을 사용할 것을 권장한다. 68 | 69 | 76 | 77 | > :arrow_double_up:[Top](#9-security) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-security) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 78 | > - [https://d2.naver.com/helloworld/318732](https://d2.naver.com/helloworld/318732) 79 | 80 | ### SQL Injection 공격 81 | * 개념 82 | * SQL 삽입공격은 웹에플리케이션에 대해서 가해지는 가장 흔한 공격 기법 중의 하나로 에플리케이션의 허점을 이용해서 데이터베이스를 비정상적으로 조작하는 기법 83 | * 방어 방법 84 | * mysql_real_escape_string을 사용하는 것만으로도 많은 공격을 차단할 수 있다. 85 | 86 | > :arrow_double_up:[Top](#9-security) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-security) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 87 | > - []() 88 | 89 | ### CSRF 공격 90 | * 개념 91 | * Cross-site request forgery, CSRF, XSRF, 사이트 간 요청 위조 92 | * 일단 사용자가 웹사이트에 로그인한 상태에서 사이트 간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다. 93 | * 방어 방법 94 | * XSS와 마찬가지로, 입력 필터링은 중요한 문제입니다. 95 | * 모든 민감한 동작에 필수로 요구되는 확인 절차가 항상 수행되도록 합니다. 96 | * 민감한 동작에 사용되는 쿠키는 짧은 수명만 갖도록 합니다. 97 | * **[참고]** XSS vs CSRF 98 | * 사이트 간 스크립팅(XSS)을 이용한 공격이 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, 99 | * 사이트간 요청 위조(CSRF)는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 100 | 101 | > :arrow_double_up:[Top](#9-security) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-security) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 102 | > - [https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies](https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies) 103 | 104 | ### XSS 공격 105 | * 개념 106 | * Cross-site 스크립팅 공격, 사이트 간 스크립팅 공격 107 | * 사용자가 입력한 정보를 출력할 때 스크립트가 실행되도록 하는 공격기법 108 | * 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다. 109 | * 이 취약점은 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 나타난다. 110 | * 이 취약점으로 해커가 사용자의 정보(쿠키, 세션 등)를 탈취하거나, 자동으로 비정상적인 기능을 수행하게 할 수 있다. 111 | * 누군가가 중간에서 사용자의 세션 아이디를 훔친다면 그 사용자처럼 로그인할 수 있게 된다. 112 | * 방어 방법 113 | * htmlspecialchars 사용 114 | * 이 함수는 html 코드를 해석하지 않고 화면에 그대로 출력하도록 변환 115 | * 쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에 116 | * 쿠키 속성 HttpOnly 옵션을 활성화한다. 117 | * HttpOnly: true를 주면 자바스크립트를 통해서 쿠키 값에 접근할 수 없다. 118 | * XSS 공격 방지 119 | * 세션 옵션 Secure을 활성화 120 | * HTTPS에서만 쿠키가 전송된다. (즉, HTTPS에서만 세션 정보를 주고받을 수 있다.) 121 | * XSS 공격 방지 122 | * 쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 꼭 마련해두는 것이 좋다. 123 | * HTTPS를 이용해서 통신 하는 것이 좋다. 124 | 125 | > :arrow_double_up:[Top](#9-security) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-security) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 126 | > - []() 127 | 128 | ### OAuth 129 | #### OAuth 개념 130 | - 사용자가 어떤 애플리케이션을 이용할 때, 비밀번호를 입력하지 않고 OAuth를 제공하는 애플리케이션의 계정 정보를 공유하여 접근 권한을 부여할 수 있는 수단 131 | - OAuth가 사용되기 전에는 보안이 취약한 구조 132 | - 각 애플리케이션이나 웹 사이트마다 개별적인 인증 방식으로 아이디와 비밀번호를 사용하여 로그인 133 | - OAuth는 제각각인 인증방식을 표준화한 것 134 | - 인증을 공유하는 애플리케이션끼리는 별도 인증과정 불필요 135 | - '인증(Authentication)' 프로토콜이 아닌 **'인가(Authorization)' 프로토콜** 136 | - 인증 : 접근 가능함을 확인하는 과정 137 | - 인가 : 허가, 접근 권한을 관리 138 | - 사용자의 확인(인증) 과정을 통해 권한을 부여(인가) 139 | 140 | #### OAuth 관련 용어 141 | - 사용자 142 | - '서비스 제공자'와 '소비자'를 사용하는 계정을 가지고있는 개인 143 | - 서비스 제공자 144 | - OAuth를 통한 접근을 지원하는 애플리케이션(Open API 제공 서비스) 145 | - 대표적으로 구글, 네이버, 카카오, 페이스북 등 146 | - 소비자 147 | - Open API를 사용하여 개발된 OAuth를 사용하여 '서비스 제공자'에게 접근하는 애플리케이션 148 | - 소비자 비밀번호 149 | - '서비스 제공자'에서 소비자가 자신임을 인증하는 키 150 | - 요청 토큰 151 | - '소비자'가 '사용자'의 접근 권한을 인증받기 위해 필요한 정보 152 | - 이후 '접근 토큰'으로 변경 153 | - 접근 토큰 154 | - 인증 후에 '사용자'가 '서비스 제공자'가 아닌 '소비자'를 통해 보호된 자원에 접근하기 위한 키를 포함한 값 155 | 156 | #### 과정 157 | - '소비자'와 '서비스 제공자' 간에 OAuth 과정 진행 158 | 1. 소비자가 서비스 제공자에게 '요청 토큰'을 요청 159 | 2. 서비스 제공자가 소비자에게 '요청 토큰' 발급 160 | 3. 소비자가 사용자를 서비스 제공자에게 이동시키고, 이 과정에서 사용자 인증 수행(인증, Authentication) 161 | 4. 사용자 인증 후, 서비스 제공자가 사용자를 소비자로 이동 162 | 5. 소비자가 '접근 토큰' 요청 163 | 6. 서비스 제공자가 '접근 토큰' 발급(권한 부여, Authorization) 164 | 7. 소비자는 '접근 토큰'을 사용하여 사용자 정보에 접근 가능 165 | 166 | > :arrow_double_up:[Top](#9-security) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-security) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 167 | > - [OAuth](https://ko.wikipedia.org/wiki/OAuth) 168 | 169 | 170 | --- 171 | 172 | ## Reference 173 | > - []() 174 | 175 | 176 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 177 | -------------------------------------------------------------------------------- /contents/spring.md: -------------------------------------------------------------------------------- 1 | # 9. Spring 2 | **:book: Contents** 3 | * [스프링 프레임워크란](#스프링-프레임워크란) 4 | * [Spring, Spring MVC, Spring Boot의 차이](#spring-spring-mvc-spring-boot의-차이) 5 | * [Bean이란](#bean이란) 6 | * [Container란](#container란) 7 | * [IOC(Inversion of Control, 제어의 역전)란](#ioc란) 8 | * [MVC 패턴이란](#mvc-패턴이란) 9 | * [DI(Dependency Injection, 의존성 주입)란](#di란) 10 | * [AOP(Aspect Oriented Programming)란](#aop란) 11 | * [POJO](#pojo) 12 | * [DAO와 DTO의 차이](#dao와-dto의-차이) 13 | * [Spring JDBC를 이용한 데이터 접근](#spring-jdbc를-이용한-데이터-접근) 14 | * [Filter와 Interceptor 차이](#filter와-interceptor-차이) 15 | 16 | --- 17 | 18 | ### 스프링 프레임워크란 19 | * 자바 엔터프라이즈 개발을 편하게 해주는 경량급 오픈소스 애플리케이션 프레임워크 20 | * **Lightweight Java Applicaion Framework** 21 | * 목표: **POJO 기반의** Enterprise Application 개발을 쉽고 편하게 할 수 있도록 한다. 22 | * Java Application을 개발하는데 필요한 하부구조(Infrastructure)를 포괄적으로 제공한다. 23 | * Spring이 하부구조를 처리하기 때문에 개발자는 Application 개발에 집중할 수 있다. 24 | * 간단히 스프링(Spring)이라고도 불린다. 25 | * 동적인 웹 사이트를 개발하기 위한 여러 가지 서비스를 제공한다. 26 | * 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자 정부 표준 프레임워크의 기반 기술 27 | 28 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 29 | > - [https://gmlwjd9405.github.io/2018/10/26/spring-framework.html](https://gmlwjd9405.github.io/2018/10/26/spring-framework.html) 30 | 31 | ### Spring Spring MVC Spring Boot의 차이 32 | * Spring 33 | * 34 | * Spring MVC 35 | * Spring Boot 36 | 37 | 38 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 39 | > - [http://blog.naver.com/PostView.nhn?blogId=sthwin&logNo=221271008423&parentCategoryNo=&categoryNo=50&viewDate=&isShowPopularPosts=true&from=search](http://blog.naver.com/PostView.nhn?blogId=sthwin&logNo=221271008423&parentCategoryNo=&categoryNo=50&viewDate=&isShowPopularPosts=true&from=search) 40 | 41 | ### Bean이란 42 | * 컨테이너 안에 들어있는 객체 43 | * 컨테이너에 담겨있으며, 필요할 때 컨테이너에서 가져와서 사용 44 | * @Bean 을 사용하거나 xml 설정을 통해 일반 객체를 Bean으로 등록할 수 있고, Bean으로 등록된 객체는 쉽게 주입하여 사용 가능 45 | 46 | #### Bean 생명주기 47 | - 객체 생성 -> 의존 설정 -> 초기화 -> 사용 -> 소멸 48 | - 스프링 컨테이너에 의해 생명주기 관리 49 | - 스프링 컨테이너 초기화 시 빈 객체 생성, 의존 객체 주입 및 초기화 50 | - 스프링 컨테이너 종료 시 빈 객체 소멸 51 | 52 | #### Bean 초기화 방법 3가지 53 | 1. 빈 초기화 메소드에 ```@PostConstruct``` 사용 54 | - 빈 정의 xml에 `````` 추가 55 | 2. ```InitializingBean``` 인터페이스의 ```afterPropertiesSet()``` 메소드 오버라이드 56 | 3. 커스텀 init() 메소드 정의 57 | - 빈 정의 xml에 ```init-method``` 속성으로 메소드 이름 지정 58 | - 또는 빈 초기화 메소드에 ```@Bean(init-method="init")``` 지정 59 | 60 | #### Bean 소멸 방법 3가지 61 | 1. 빈 소멸 메소드에 ```@PreDestroy``` 사용 62 | - 빈 정의 xml에 `````` 추가 63 | 2. ```DisposableBean``` 인터페이스의 ```destroy()``` 메소드 오버라이드 64 | 3. 커스텀 destroy() 메소드 정의 65 | - 빈 정의 xml에 ```destroy-method``` 속성으로 메소드 이름 지정 66 | 67 | ##### 권장하는 방법 68 | - 1번 방법 (권장) 69 | - 사용 방법이 간결하며 코드에서 초기화 메소드가 존재함을 쉽게 파악 가능하여 xml 설정 방법보다 직관적 70 | - 2번 방법 (지양) 71 | - 빈 코드에 스프링 인터페이스가 노출되어 권장하지 않으며 간결하지 않은 방법 72 | - 3번 방법 73 | - 빈 코드에 스프링 인터페이스는 노출되지 않지만, 코드만으로 초기화 메소드 호출 여부를 알 수 없는 단점 74 | 75 | #### Bean Scope 76 | * **singleton (default)** 77 | * 애플리케이션에서 Bean 등록 시 singleton scope로 등록 78 | * Spring IoC 컨테이너 당 한 개의 인스턴스만 생성 79 | * 컨테이너가 Bean 가져다 주입할 때 항상 같은 객체 사용 80 | * 메모리나 성능 최적화에 유리 81 | * **prototype** 82 | * 컨테이너에서 Bean 가져다 쓸 때 항상 다른 인스턴스 사용 83 | * 모든 요청에서 새로운 객체 생성 84 | * gc에 의해 Bean 제거 85 | * request 86 | * Bean 등록 시 하나의 HTTP request 생명주기 안에 단 하나의 Bean만 존재 87 | * 각각의 HTTP 요청은 고유 Bean 객체 보유 88 | * Spring MVC Web Application에서 사용 89 | * session 90 | * 하나의 HTTP Session 생명주기 안에 단 하나의 Bean만 존재 91 | * Spring MVC Web Application에서 사용 92 | * global session 93 | * 하나의 global HTTP Session 생명주기 안에 한 개의 Bean 지정 94 | * Spring MVC Web Application에서 사용 95 | * application 96 | * ServletContext 생명주기 안에 한 개의 Bean 지정 97 | * Spring MVC Web Application에서 사용 98 | 99 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 100 | > - [[Spring] IOC(Inversion Of Control): 제어 역전](https://velog.io/@max9106/Spring-IOC%EB%AF%B8%EC%99%84) 101 | > - [[Spring] Spring Bean의 개념과 Bean Scope 종류](https://gmlwjd9405.github.io/2018/11/10/spring-beans.html) 102 | > - [Spring 빈/컨테이너 생명주기 (Lifecycle)](https://flowarc.tistory.com/entry/Spring-%EB%B9%88%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EC%83%9D%EB%AA%85%EC%A3%BC%EA%B8%B0-Lifecycle) 103 | > - [SpringMVC :: 스프링 컨테이너의 생명주기, 빈의 생명주기 (Life cycle), InitialzingBean, DisposableBean, @PreDestroy, @PostConstruct](https://hongku.tistory.com/106) 104 | > - [[Spring] 빈(bean)생명주기 메소드](https://cornswrold.tistory.com/100) 105 | 106 | ### Container란 107 | - 컨테이너(Container)는 보통 인스턴스의 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능을 제공하도록하는 것이라 할 수 있다. 다시말해, 컨테이너란 당신이 작성한 코드의 처리과정을 위임받은 독립적인 존재라고 생각하면 된다. 컨테이너는 적절한 설정만 되어있다면 누구의 도움없이도 프로그래머가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸을 컨트롤해준다. 108 | 109 | - Spring 프레임워크는 다른 프레임워크들과 달리 컨테이너 기능을 제공하고 있다. 이와 같은 컨테이너 기능을 제공하는 것이 가능하도록 하는 것이 IoC 패턴이다. 110 | 111 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 112 | > - [http://limmmee.tistory.com/13](http://limmmee.tistory.com/13) 113 | > - [http://wiki.javajigi.net/pages/viewpage.action?pageId=281](http://wiki.javajigi.net/pages/viewpage.action?pageId=281) 114 | 115 | ### IoC란 116 | - IoC(Inversion of Control, 제어의 역전)란 117 | - 객체의 생성에서부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀐 것을 의미, 또는 제어 권한을 자신이 아닌 다른 대상에게 위임하는 것이다. 118 | - 이 방식은 대부분의 프레임워크에서 사용하는 방법으로, 개발자는 필요한 부분을 개발해서 끼워 넣기의 형태로 개발하고 실행하게 된다. 프레임워크가 이러한 구조를 가지기 때문에 개발자는 프레임워크에 필요한 부품을 개발하고 조립하는 방식의 개발을 하게 된다. 119 | - 이렇게 조립된 코드의 최종 호출은 개발자에 의해서 제어되는 것이 아니라 프레임워크의 내부에서 결정된 대로 이뤄지게 되는데, 이러한 현상을 "제어의 역전"이라고 표현한다. 120 | - Spring에서의 IoC 121 | - Spring 프레임워크에서 지원하는 Ioc Container는 우리들이 흔히 개발하고 사용해왔던 일반 POJO(Plain Old Java Object)의 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능들을 제공한다. 122 | - 라이브러리와 프레임워크의 차이 123 | - IoC의 개념이 적용되었나의 차이 124 | - 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 단지 동작히는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 시용할 뿐이다. 125 | - 반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도히는 중에 개발자가 만든 애플리케이션 코드를 시용하도록 만드는 방식이다. 126 | 127 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 128 | > - [http://wiki.javajigi.net/pages/viewpage.action?pageId=3664](http://wiki.javajigi.net/pages/viewpage.action?pageId=3664) 129 | > - [http://limmmee.tistory.com/13](http://limmmee.tistory.com/13) 130 | > - [http://wiki.javajigi.net/pages/viewpage.action?pageId=281](http://wiki.javajigi.net/pages/viewpage.action?pageId=281) 131 | 132 | ### MVC 패턴이란 133 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 134 | > - []() 135 | 136 | ### DI란 137 | - DI? 138 | - Dependency Injection, 의존성 주입 139 | - Dependency Injection은 Spring 프레임워크에서 지원하는 IoC의 형태이다. 140 | - DI는 클래스 사이의 의존관계를 빈 설정 정보를 바탕으로 컨테이너가 자동적으로 연결해주는 것을 말한다. 개발자들은 제어를 담당할 필요없이 빈 설정 파일에 의존관계가 필요하다는 정보만 추가해주면 된다. 141 | - 컨테이너가 실행 흐름의 주체가 되어 애플리케이션 코드에 의존관계를 주입해주는 것. 142 | - 의존성(Dependency) 143 | - 현재 객체가 다른 객체와 상호작용(참조)하고 있다면 다른 객체들을 현재 객체의 의존이라 한다. 144 | - 의존성이 위험한 이유 145 | - 하나의 모듈이 바뀌면 의존한 다른 모듈까지 변경되야 한다. 146 | - 테스트 가능한 어플을 만들 때 의존성이 있으면 유닛테스트 작성이 어렵다. 147 | - 유닛테스트의 목적 자체가 다른 모듈로부터 독립적으로 테스트하는 것을 요구한다. 148 | - DI의 특징 149 | - ‘new’를 사용해 모듈 내에서 다른 모듈을 초기화하지 않으려면 객체 생성은 다른 곳에서 하고, 생성된 객체를 참조하면 된다. 150 | - 의존성 주입은 Inversion of Control 개념을 바탕으로 한다. 클래스가 외부로부터 의존성을 가져야한다. 151 | - DI가 필요한 이유(DI의 장점) 152 | - 클래스를 재사용 할 가능성을 높이고, 다른 클래스와 독립적으로 클래스를 테스트 할 수 있다. 153 | - 비즈니스 로직의 특정 구현이 아닌 클래스를 생성하는데 매우 효과적 154 | - DI의 세가지 방법 155 | - Contructor Injection : 생성자 삽입 156 | - Method(Setter) Injection : 메소드 매개 변수 삽입 157 | - Field Injection : 멤버 변수 삽입 158 | 159 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 160 | > - [http://www.nextree.co.kr/p11247/](http://www.nextree.co.kr/p11247/) 161 | > - [http://wiki.javajigi.net/pages/viewpage.action?pageId=281](http://wiki.javajigi.net/pages/viewpage.action?pageId=281) 162 | > - [http://tony-programming.tistory.com/entry/Dependency-의존성-이란](http://tony-programming.tistory.com/entry/Dependency-의존성-이란) 163 | 164 | ### AOP란 165 | * AOP(Aspect Oriented Programming)란 166 | - Aspect Oriented Programming, 관점 지향 프로그래밍 167 | - 어떤 로직을 기준으로 핵심 관점과 부가 관점을 나누고, 관점을 기준으로 모듈화하는 것 168 | - 핵심 관점은 주로 핵심 비즈니스 로직 169 | - 부가 관점은 핵심 로직을 실행하기 위한 데이터베이스 연결, 로깅, 파일 입출력 등 170 | 171 | * AOP 목적 172 | - 소스 코드에서 여러 번 반복해서 쓰는 코드(= 흩어진 관심사, Concern)를 Aspect로 모듈화하여 핵심 로직에서 분리 및 재사용 173 | - 개발자가 핵심 로직에 집중할 수 있게 하기 위함 174 | - 주로 부가 기능을 모듈화 175 | 176 | * AOP 주요 용어 177 | - **Aspect** 178 | - 흩어진 관심사를 모듈화 한 것 179 | - Advice + PointCut 180 | - **Target** 181 | - Aspect를 적용하는 곳(클래스, 메소드 등) 182 | - **Advice** 183 | - 실질적으로 수행해야 하는 기능을 담은 구현체 184 | - **JoinPoint** 185 | - Advice가 적용될 위치 186 | - 끼어들 수 있는 지점 187 | - ex. 메소드 진입 시, 생성자 호출 시, 필드에서 값 꺼낼 때 등 188 | - **PointCut** 189 | - JoinPoint의 상세 스펙 정의 190 | - 더욱 구체적으로 Advice가 실행될 지점 지정 191 | - **Weaving** 192 | - PointCut에 의해 결정된 Target의 JoinPoint에 Advice를 삽입하는 과정 193 | 194 | * AOP 적용 방법 195 | 1. 컴파일 시 적용 196 | - AspectJ가 사용하는 방법 197 | - 자바 파일을 클래스 파일로 만들 때 Advice 소스가 추가되어 조작된 바이트 코드 생성하는 방법 198 | 2. 로드 시 적용 199 | - AspectJ가 사용하는 방법 200 | - 컴파일 후 컴파일 된 클래스를 로딩하는 시점에 Advice 소스를 끼워넣는 방법 201 | 3. 런타임 시 적용 202 | - **Spring AOP**가 사용하는 방법 203 | - 스프링은 런타임 시 Bean 생성 204 | - A라는 Bean 만들 때 A라는 타입의 프록시 Bean도 생성하고, 프록시 Bean이 A의 메소드 호출 직전에 Advice 소스를 호출한 후 A의 메소드 호출 205 | 206 | * Spring AOP 특징 207 | - [프록시 패턴](https://velog.io/@max9106/Spring-%ED%94%84%EB%A1%9D%EC%8B%9C-AOP-xwk5zy57ee) 기반의 AOP 구현체 208 | - Target 객체에 대한 프록시를 만들어 제공 209 | - Target을 감싸는 프록시는 런타임 시 생성 210 | - 접근 제어 및 부가 기능 추가를 위해 프록시 객체 사용 211 | - 프록시가 Target 객체의 호출을 가로채 Advice 수행 전/후 핵심 로직 호출 212 | - 스프링 Bean에만 AOP 적용 가능 213 | - 메소드 조인 포인트만 지원하여 메소드가 호출되는 런타임 시점에만 Advice 적용 가능 214 | - 모든 AOP기능을 제공하지는 않으며 스프링 IoC와 연동하여 엔터프라이즈 애플리케이션의 각종 문제(중복 코드, 프록시 클래스 작성의 번거로움, 객체 간 관계 복잡도 증가)에 대한 해결책 지원 목적 215 | 216 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 217 | > - [[Spring] 스프링 AOP (Spring AOP) 총정리 : 개념, 프록시 기반 AOP, @AOP](https://engkimbs.tistory.com/746) 218 | > - [[Spring] AOP란?](https://velog.io/@max9106/Spring-AOP%EB%9E%80-93k5zjsm95) 219 | > - [Spring AOP, Aspect 개념 특징, AOP 용어 정리](https://shlee0882.tistory.com/206) 220 | 221 | ### POJO 222 | 번역하면 '평범한 구식 자바 객체'. 즉 프레임워크 인터페이스나 클래스를 구현하거나 확장하지 않는 단순한 클래스. 223 | - EJB와 엔터프라이즈 서비스 224 | - EJB(Enterprise JavaBean) 225 | - 기업업무처리의 IT시스템에 대한 의존도가 높아지면서 시스템이 다뤄야 하는 **비즈니스 로직 자체가 점차 복잡**해지고, 많은 사용자의 처리요구를 빠르게 안정적이면서 확장 가능한 형태로 유지하기위해 필요한 **로우레벨의 기술적인(트랜젝션 처리, 상태관리, 멀티쓰레딩, 리소스풀링, 보안등) 처리**가 요구됐다. 226 | - EJB의 비전은 **'EJB는 애플리케이션 개발을 쉽게 만들어준다. 애플리케이션 개발자는 로우레벨의 기술들에 관심을 가질 필요도 없다.'** 였지만, 결론적으론 불필요할만큼 **과도한 엔지니어링으로 실패한 대표적인 케이스**가 되었다. 227 | - 가장 최악의 문제점은 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 **특징과 장점을 포기해야했다는 것**이다. EJB 빈은 상속과 다형성등의 혜택을 제대로 누릴 수 없었다. 228 | - 마틴 파울러는 **EJB와 같은 잘못 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바 언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO 방식으로 돌아서야 한다**고 지적했다. 229 | - 특징 230 | - Java에서 제공하는 API 외에 종속되지 않음 231 | - 특정 규약, 환경에 종속되지 않음 232 | - 환경에 종속되지 않는 것의 장점 233 | - 코드의 간결함 (비즈니스 로직과 특정 환경/low 레벨 종속적인 코드를 분리하므로 단순) 234 | - 비즈니스 로직과 특정 환경이 분리되므로 단순함 235 | - 자동화 테스트에 유리 (환경 종속적인 코드는 자동화 테스트가 어렵지만, POJO는 테스트가 매우 유연) 236 | - 객체지향 설계의 자유로운 사용 237 | 238 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 239 | > - [http://limmmee.tistory.com/8?category=654011](http://limmmee.tistory.com/8?category=654011) 240 | 241 | ### DAO와 DTO의 차이 242 | - **DAO(Data Access Object)** 243 | - DB의 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 객체를 말한다. 244 | - DB에 접근을 하기위한 로직과 비즈니스 로직을 분리하기 위해서 사용 한다. 245 | - **DTO(Data Transfer Object)** 246 | - 계층간 데이터 교환을 위한 자바빈즈를 말한다. 247 | - 여기서 말하는 계층은 Controller, View, Business Layer, Persistent Layer 이다. 248 | - 일반적인 DTO는 로직을 갖고 있지 않는 순수한 데이터 객체이며, 속성과 그 속성에 접근하기 위한 getter, setter 메소드만 가진 클래스이다. 249 | - VO(Value Object) 라고도 불린다. 250 | - DTO와 동일한 개념이지만 read only 속성을 가진다. 251 | 252 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 253 | > - [https://jungwoon.github.io/common%20sense/2017/11/16/DAO-VO-DTO/](https://jungwoon.github.io/common%20sense/2017/11/16/DAO-VO-DTO/) 254 | 255 | ### Spring JDBC를 이용한 데이터 접근 256 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 257 | > - []() 258 | 259 | ### Filter와 Interceptor 차이 260 | 261 | #### Filter, Interceptor 262 | * 애플리케이션에서 자주 사용되는 기능(공통 부분)을 분리하여 관리할 수 있도록 Spring이 제공하는 기능 263 | 264 | #### Filter, Interceptor 흐름 265 | 266 | ![filterInterceptor](./images/filterInterceptor.jpg) 267 | 1. 서버 실행 시 Servlet이 올라오는 동안 init 후 doFilter 실행 268 | 2. Dispatcher Servlet을 지나쳐 Interceptor의 preHandler 실행 269 | 3. 컨트롤러를 거쳐 내부 로직 수행 후, Interceptor의 postHandler 실행 270 | 4. doFilter 실행 271 | 5. Servlet 종료 시 destroy 272 | 273 | #### Filter 특징 274 | * Dispatcher Servlet 이전에 수행되고, 응답 처리에 대해서도 변경 및 조작 수행 가능 275 | * WAS 내의 ApplicationContext에서 등록된 필터가 실행 276 | * WAS 구동 시 FilterMap이라는 배열에 등록되고, 실행 시 Filter chain을 구성하여 순차적으로 실행 277 | * Spring Context 외부에 존재하여 Spring과 무관한 자원에 대해 동작 278 | * 일반적으로 web.xml에 설정 279 | * 예외 발생 시 Web Application에서 예외 처리 280 | * ex. 인코딩 변환, XSS 방어 등 281 | * 실행 메소드 282 | * init() : 필터 인스턴스 초기화 283 | * doFilter() : 실제 처리 로직 284 | * destroy() : 필터 인스턴스 종료 285 | 286 | #### Interceptor 특징 287 | * Dispatcher Servlet 이후 Controller 호출 전, 후에 끼어들어 기능 수행 288 | * Spring Context 내부에서 Controller의 요청과 응답에 관여하며 모든 Bean에 접근 가능 289 | * 일반적으로 servlet-context.xml에 설정 290 | * 예외 발생 시 @ControllerAdvice에서 @ExceptionHandler를 사용해 예외 처리 291 | * ex. 로그인 체크, 권한 체크, 로그 확인 등 292 | * 실행 메소드 293 | * preHandler() : Controller 실행 전 294 | * postHandler() : Controller 실행 후 295 | * afterCompletion() : view Rendering 후 296 | 297 | ##### Filter, Interceptor 차이점 요약 298 | * Filter는 WAS단에 설정되어 Spring과 무관한 자원에 대해 동작하고, Interceptor는 Spring Context 내부에 설정되어 컨트롤러 접근 전, 후에 가로채서 기능 동작 299 | * Filter는 doFilter() 메소드만 있지만, Interceptor는 pre와 post로 명확하게 분리 300 | * Interceptor의 경우 AOP 흉내 가능 301 | * handlerMethod(@RequestMapping을 사용해 매핑 된 @Controller의 메소드)를 파라미터로 제공하여 메소드 시그니처 등 추가 정보를 파악해 로직 실행 여부 판단 가능 302 | 303 | 304 | > :arrow_double_up:[Top](#9-spring) :leftwards_arrow_with_hook:[Back](https://github.com/WeareSoft/tech-interview#9-spring) :information_source:[Home](https://github.com/WeareSoft/tech-interview#tech-interview) 305 | > - [[Spring] Filter, Interceptor, AOP 차이 및 정리](https://goddaehee.tistory.com/154) 306 | > - [[Spring] Filter, Interceptor, AOP 차이](https://velog.io/@sa833591/Spring-Filter-Interceptor-AOP-%EC%B0%A8%EC%9D%B4-yvmv4k96) 307 | > - [Spring Filter와 Interceptor](https://jaehun2841.github.io/2018/08/25/2018-08-18-spring-filter-interceptor/#spring-request-flow) 308 | > - [(Spring)Filter와 Interceptor의 차이](https://supawer0728.github.io/2018/04/04/spring-filter-interceptor/) 309 | 310 | --- 311 | 312 | ## Reference 313 | > - []() 314 | 315 | 316 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 317 | -------------------------------------------------------------------------------- /contents/template.md: -------------------------------------------------------------------------------- 1 | # 1. Data Structure 2 | 3 | ### title 4 | > - []() 5 | 6 | 7 | --- 8 | 9 | ## Reference 10 | > - []() 11 | 12 | 13 | ## :house: [Home](https://github.com/WeareSoft/tech-interview) 14 | --------------------------------------------------------------------------------