A. app和web的區別是什麼
基於網路平台的應用和需要下載客戶端的區別，也就是相當於網頁版qq和客戶端安裝包版qq的區別
B. 手機app應用的伺服器與網頁web的伺服器區別大嗎用java寫伺服器的話適合共用嗎謝謝
web伺服器是網站、郵件系統、ftp等功能用的。應用伺服器是公司辦公系統用的，主要支持文件傳輸、列印、OA系統運行等。java開發入門和提高這個問題先確定想學的話，買幾本書好好看看。看兩本書你就都明白了這種編程方面的事情，聊天是說不明白的。
C. App測試與Web測試的區別是什麼
App測試和web測試都屬於軟體測試，它們在整個測試流程上沒有太大的區別，主要的區別體現在以下幾個方面： 功能、性能、兼容性、專項測試、操作方式 等，下面我們一一舉例說明。
1、功能方面：
App和web基於不同的網路架構，App是C/S架構（即客戶端/服務端），web是B/S架構（即瀏覽器/伺服器），對於web來說，一般情況下如果服務端發生了更新，那麼瀏覽器端也會隨著更新，這個更新是即時的，不需要用戶額外操作的，用戶只需要打開瀏覽器訪問具體的伺服器地址便可以完成這個過程；而App端則首先需要用戶在自己的終端上安裝一個應用，當服務端發生了變更時，不能保證每個客戶端的內容都獲得更新，除非用戶自己手動選擇更新。
2、性能方面：
App和web在性能上都會關注響應時間以及負載情況等，但App還需要額外考慮應用的耗電情況、流量、CPU和內存佔用情況、後台進程等。
3、兼容性方面：
Web是基於瀏覽器架構，在兼容性方面，一般只需要考慮所使用的瀏覽器版本，如Google Chrome、edge、Firefox等，而App就復雜一些，除了要關注終端系統，如iOS、macOS或Android等移動操作系統，還需要測試不同的硬體設備型號，比如iPhone系列、華為、小米、OPPO、vivo等廠商，每一家在設備的CPU、屏幕尺寸、解析度等硬體系統上都是有差別的，App測試需要確保在軟體和硬體系統上的兼容性。
4、專項測試：
正如我們前面所說的，App是基於C/S架構，所以App測試需要關注某些專項測試，比如客戶端的安裝、卸載和更新，而web是基於B/S架構是不需要考慮這些的。
此外，App還要考慮一些特殊場景，比如系統和應用的優先順序、操作許可權、應用奔潰、後台進程、中斷、重啟、以及網路專項測試等，網路專項又包括網路切換（如2/3/4/5G/WIFI等）、網路中斷以及弱網測試等。
5、操作方式：
Web端在操作方式上是基於滑鼠點擊和鍵盤輸入實現的，一般來說相對簡單，而App端是基於屏幕，一般是通過觸摸屏幕或者功能設備（如觸摸筆）來實現具體步驟的，由於操作方式的不同，App測試時要留意屏幕的旋轉和縮放、多點觸控、特殊事件觸發區域、應用層等。
小結
隨著軟體和技術的不斷發展，App和web端測試在具體細分領域的區別會越來越明顯，有效地加深二者異同的認識對於我們的測試能力的提升具有良好的指引作用，或許測試在具體領域還會進一步細分，但是對於測試工程師能力的要求會不斷地提高，如何提高對於不同分支的認知情況值得我們去思考。
D. app的伺服器可以用web伺服器嗎
伺服器分為虛擬主機 vps 雲伺服器 獨立伺服器
所有伺服器都能用作web伺服器，但是一般是用虛擬主機，節約成本
但是APP的話 就不能用虛擬主機 其它伺服器都可以使用
E. web server與app server有什麼不同
1，web server（web伺服器）：
web伺服器處理HTTP協議。當收到一個HTTP請求之後，web伺服器會返回一個HTTP響應，比如一個HTML頁面。為了處理請求，它可能響應一個靜態的HTML頁面、圖片、重定向，或者代理（delegate）其他動態響應。
這些動態響應可以由其他程序生成，包括CGI腳本，JSPs，servlets，ASPs，伺服器端的Javascript，或者其他伺服器端技術。而這些伺服器端程序響應，大多數時候都表現為HTML頁面，供瀏覽器訪問。
2，app server（App伺服器）：
根據我們的定義，app伺服器可以基於各種不同的協議（可能包含HTTP協議），為客戶端程序提供應用邏輯的處理。不同於web伺服器主要發送用來展示在瀏覽器上的HTML頁面，app伺服器為客戶端程序處理應用邏輯方面問題。應用程序使用這些邏輯，就如同調用一個對象的方法（或者面向過程編程中的函數）一樣簡單。
web伺服器提供頁面給瀏覽器，而app伺服器提供客戶端可以調用的介面。
具體而言，我們可以說：Web伺服器處理HTTP請求，而app伺服器基於多種不同的協議，處理應用程序的邏輯問題。
(5)web伺服器與app擴展閱讀：
解析
Web伺服器可以解析(handles)HTTP協議。當Web伺服器接收到一個HTTP請求(request)，會返回一個HTTP響應(response)，例如送回一個HTML頁面。
為了處理一個請求(request)，Web伺服器可以響應(response)一個靜態頁面或圖片，進行頁面跳轉(redirect)。
或者把動態響應(dynamic response)的產生委託(delegate)給一些其它的程序例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本。
伺服器端(server-side)JavaScript，或者一些其它的伺服器端(server-side)技術。無論它們(譯者註：腳本)的目的如何，這些伺服器端(server-side)的程序通常產生一個HTML的響應(response)來讓瀏覽器可以瀏覽。
web服務
通俗的講，Web伺服器傳送(serves)頁面使瀏覽器可以瀏覽，然而應用程序伺服器提供的是客戶端應用程序可以調用(call)的方法(methods)。
確切一點，你可以說：Web伺服器專門處理HTTP請求(request)，但是應用程序伺服器是通過很多協議來為應用程序提供(serves)商業邏輯(business logic)。
F. 手機APP和web服務端 跨域問題
跨域問題來源於JavaScript的同源策略，即只有 協議+主機名+埠號 (如存在)相同，則允許相互訪問。也就是說JavaScript只能訪問和操作自己域下的資源，不能訪問和操作其他域下的資源。
在以前，前端和後端混雜在一起， 比如JavaScript直接調用同系統裡面的一個Httphandler，就不存在跨域的問題，但是隨著現代的這種多種客戶端的流行，比如一個應用通常會有Web端，App端，以及WebApp端，各種客戶端通常會使用同一套的後台處理邏輯，即API， 前後端分離的開發策略流行起來，前端只關注展現，通常使用JavaScript，後端處理邏輯和數據通常使用WebService來提供json數據。一般的前端頁面和後端的WebService API通常部署在不同的伺服器或者域名上。這樣，通過ajax請求WebService的時候，就會出現同源策略的問題。
需要說明的是，同源策略是JavaScript裡面的限制，其他的編程語言，比如在C#，Java或者iOS等其他語言中是可以調用外部的WebService，也就是說，如果開發Native應用，是不存在這個問題的，但是如果開發Web或者Html5如WebApp，通常使用JavaScript ajax對WebService發起請求然後解析返回的值，這樣就可能存在跨域的問題。
一般的，很容易想到，將外部的資源搬到同一個域上就能解決同源策略的限制的。即在Web網站上同時開發一個Http服務端頁面，所有JavaScript的請求都發到這個頁面上來，這個頁面在內部使用其他語言去調用外部的WebService。即添加一個代理層。這種方式可以解決問題，但是不夠直接和高效。
目前，比較常見的跨域解決方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解決方案需要客戶端和服務端配合如JSOP，一些則只需要服務端配合處理比如CORS。下面分別介紹這兩種跨域方案，以及服務端WebService如何支持這兩種跨域方案。
JSONP以及WebService的支持
同源策略下，某個伺服器是無法獲取到伺服器以外的數據，但是html裡面的img,iframe和script等標簽是個例外，這些標簽可以通過src屬性請求到其他伺服器上的數據。而JSONP就是通過script節點src調用跨域的請求。
當我們向伺服器提交一個JSONP的請求時,我們給服務傳了一個特殊的參數,告訴服務端要對結果特殊處理一下。這樣服務端返回的數據就會進行一點包裝，客戶端就可以處理。
舉個例子，服務端和客戶端約定要傳一個名為callback的參數來使用JSONP功能。比如請求的參數如下:
http://www.example.net/sample.aspx?callback=mycallback
如果沒有後面的callback參數，即不使用JSONP的模式，該服務的返回結果可能是一個單純的json字元串，比如：
{ foo : 'bar' }
如果和服務端約定jsonp格式，那麼服務端就會處理callback的參數，將返回結果進行一下處理，比如處理成：
mycallback({ foo : 'bar' })
可以看到，這其實是一個函數調用，比如可以實現在頁面定義一個名為mycallback的回調函數：
mycallback = function(data)
{
alert(data.foo);
};
現在，請求的返回值回去觸發回調函數，這樣就完了了跨域請求。
如果使用ServiceStack創建WebService的話，支持Jsonp方式的調用很簡單，只需要在AppHost的Configure函數裡面注冊一下對響應結果進行過濾處理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFilters.Add((req, res, dto) =>
{
var func = req.QueryString.Get("callback");
if (!func.isNullOrEmpty())
{
res.AddHeader("Content-Type", ContentType.Html);
res.Write("<script type='text/javascript'>{0}({1});</script>"
.FormatWith(func, dto.ToJson()));
res.Close();
}
});
}
JSONP跨域方式比較方便，也支持各種較老的瀏覽器，但是缺點很明顯，他只支持GET的方式提交，不支持其他Post的提交，Get方式對請求的參數長度有限制，在有些情況下可能不滿足要求。所以下面就介紹一下CORS的跨域解決方案。
CORS跨域及WebService的支持
先來看一個例子，我們新建一個基本的html頁面，在裡面編寫一個簡單的是否支持跨域的小腳本，如下：
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>AJAX跨域請求測試</title>
</head>
<body>
<input type='button' value='開始測試' onclick='crossDomainRequest()' />
<div id="content"></div>
<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
document.getElementById("content").innerHTML = "開始……";
if (xhr) {
xhr.open('POST', url, true);
xhr.onreadystatechange = handler;
xhr.send();
} else {
document.getElementById("content").innerHTML = "不能創建 XMLHttpRequest";
}
}
function handler(evtXHR) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var response = xhr.responseText;
document.getElementById("content").innerHTML = "結果：" + response;
} else {
document.getElementById("content").innerHTML = "不允許跨域請求。";
}
}
else {
document.getElementById("content").innerHTML += "<br/>執行狀態 readyState：" + xhr.readyState;
}
}
//]]>
</script>
</body>
</html>
然後保存為本地html文件，可以看到，這個腳本中，對本地的服務http://localhost:1337/json/Hello 發起了一個請求， 如果使用chrome 直接打開，會看到輸出的結果，不允許跨域請求。 在javascript控制台程序中同樣可以看到錯誤提示：
那麼如果在返回響應頭header中注入Access-Control-Allow-Origin，這樣瀏覽器檢測到header中的Access-Control-Allow-Origin，則就可以跨域操作了。
同樣，如果使用ServcieStack，在很多地方可以支持CORS的跨域方式。最簡單的還是在AppHost的Configure函數裡面直接寫入：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
this.AddPlugin(new CorsFeature());
}
這樣就可以了，相當於使用默認的CORS配置：
CorsFeature(allowedOrigins:"*",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);
如果僅僅允許GET和POST的請求支持CORS，則只需要改為：
Plugins.Add(new CorsFeature(allowedMethods: "GET, POST"));
當然也可以在AppHost的Config裡面設置全局的CORS，如下：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
base.SetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "*" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}
現在運行WebService，使用postman或者Chrome調用這個請求，可以看到返回的值頭文件中，已經加上了響應頭，並且可以正常顯示返回結果了：
CORS使用起來簡單，不需要客戶端的額外處理，而且支持Post的方式提交請求，但是CORS的唯一一個缺點是對客戶端的瀏覽器版本有要求，支持CORS的瀏覽器機器版本如下：
總結
本文介紹了JavaScript中的跨域基本概念和產生的原因，以及如何解決跨域的兩種方法，一種是JSONP 一種是 CORS,在客戶端Javascript調用服務端介面的時候，如果需要支持跨域的話，需要服務端支持。JSONP的方式就是服務端對返回的值進行回調函數包裝，他的優點是支持眾多的瀏覽器， 缺點是僅支持Get的方式對服務端請求。另一種主流的跨域方案是CORS，他僅需要服務端在返回數據的時候在相應頭中加入標識信息。這種方式非常簡便。唯一的缺點是需要瀏覽器的支持，一些較老的瀏覽器可能不支持CORS特性。
跨域支持是創建WebService時應該考慮的一個功能點，希望本文對您在這邊面有所幫助，文中是使用ServiceStack來演示跨域支持的，如果您用的WCF的話，知道跨域原理的前提下，實現跨域應該不難。
參考資料：
https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflow.com/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflow.com/questions/15224038/rename-callback-parameter-for-jsonp
G. web伺服器和應用伺服器的區別
一、指代不同
1、web伺服器：叫網頁伺服器或web伺服器。WEB伺服器也稱為WWW(WORLD WIDE WEB)伺服器，主要功能是提供網上信息瀏覽服務。
2、應用伺服器：指通過各種協議把商業邏輯曝露給客戶端的程序。
二、功能不同
1、web伺服器：可以解析(handles)HTTP協議。當Web伺服器接收到一個HTTP請求(request)，會返回一個HTTP響應(response)，例如送回一個HTML頁面。
2、應用伺服器：提供了訪問商業邏輯的途徑以供客戶端應用程序使用。應用伺服器使用此商業邏輯就像調用對象的一個方法一樣。
三、特點不同
1、web伺服器：傳送(serves)頁面使瀏覽器可以瀏覽。
2、應用伺服器：應用程序伺服器是通過很多協議來為應用程序提供(serves)商業邏輯(business logic)。
H. 手機網站和手機app的有什麼區別
首先手機網站和手機APP肯定不是同一產品，但是在某些功能上會有吻合之處，那麼手機網站和手機app相比之下又有什麼具體區別呢？\x0d\x0a第一：成本上\x0d\x0aapp：需要投入客戶端和服務端開發，以及耗費開銷支持多平台和多設備。\x0d\x0a移動Web：僅需H5頁面開發，使用響應式設計的移動Web可到處運行。\x0d\x0a第二：就是用戶使用門檻上\x0d\x0a\x0d\x0aapp：需要下載並等待安裝，佔用手機容量，無Wi-Fi下流量耗費大。\x0d\x0a移動Web：支持跨平台，無安裝成本，用戶門檻較低。\x0d\x0a第三：就是在追蹤數據方面\x0d\x0a\x0d\x0aapp：下載來源無法追蹤，對渠道細分統計能力有限。\x0d\x0a移動Web：方便追蹤用戶來源，媲美PC瀏覽器下常規站點統計。\x0d\x0a第四：能否快速做出調整\x0d\x0a\x0d\x0aapp：傷不起的審核周期，遇到緊急問題無法快速處理。\x0d\x0a移動Web：站點伺服器自己可控，利於快速更新迭代。\x0d\x0a盡管移動Web有如上諸多優勢，但不可否認的是，瀏覽的體驗短期內還無法超越原生應用。那麼，對於生長在移動Web上的業務和服務，如何做好設計確提升用戶體驗將尤為重要。移動Web並不是把PC端內容直接搬到手機上來顯示，而是需要結合移動端用戶的使用場景，突出最核心的功能給用戶，並保持界面簡潔。
I. 伺服器APP伺服器與WEB伺服器有什麼區別
場景不一樣唄。web就是提供一種服務就行了。 app伺服器需要提供多種服務模式。
J. app伺服器的配置和web伺服器配置是一樣的嘛的嗎
web伺服器處理HTTP協議。當收到一個HTTP請求之後，web伺服器會返回一個HTTP響應，比如一個HTML頁面。為了處理請求，它可能響應一個靜態的HTML頁面、圖片、重定向，或者代理（delegate）其他動態響應。這些動態響應可以由其他程序生成，包括CGI腳本，JSPs，servlets，ASPs，伺服器端的Javascript，或者其他伺服器端技術。而這些伺服器端程序響應，大多數時候都表現為HTML頁面，供瀏覽器訪問。