GN Language and Operation

GN Language and Operation

Differences and similarities to Blaze

Blaze is Google's internal build system, now publicly released as Bazel. It has inspired a number of other systems such as Pants and Buck.

In Google's homogeneous environment, the need for conditionals is very low and they can get by with a few hacks (abi_deps). Chrome uses conditionals all over the place and the need to add these is the main reason for the files looking different.

GN also adds the concept of “configs” to manage some of the trickier dependency and configuration problems which likewise don't arise on the server. Blaze has a concept of a “configuration” which is like a GN toolchain, but built into the tool itself. The way that toolchains work in GN is a result of trying to separate this concept out into the build files in a clean way.

GN keeps some GYP concept like “all dependent” settings which work a bit differently in Blaze. This is partially to make conversion from the existing GYP code easier, and the GYP constructs generally offer more fine-grained control (which is either good or bad, depending on the situation).

GN also uses GYP names like “sources” instead of “srcs” since abbreviating this seems needlessly obscure, although it uses Blaze's “deps” since “dependencies” is so hard to type. Chromium also compiles multiple languages in one target so specifying the language type on the target name prefix was dropped (e.g. from cc_library).

The Confusatory — iOS Debugging: Device Console Without Wires

The Confusatory — iOS Debugging: Device Console Without Wires: The Confusatory
cbowns’s tumblr.
iOS Debugging: Device Console Without Wires
For years, I’ve wanted to wirelessly view my iOS device’s console log. The system log often contains useful information from the kernel, system daemons, and any currently-running apps. Xcode briefly supported wireless debugging in Xcode 4, and this included wireless console log access, but it was pulled from later versions and has never re-appeared.
Using libimobiledevice (installed via homebrew), you can wirelessly view the console of any device which your host computer has a pairing record for (i.e. the device has been plugged in, unlocked, and “Trusts” the host computer. More info about pairing records is available around the internet.)
% brew install libimobiledevice
% idevice_id --list to list available device UDIDs.
% idevicesyslog -u , with the device connected via USB or available on the local wireless network.
In informal testing, this works on my home network from a laptop running OS X 10.10.5 to two iOS devices running iOS 8.3.
Please comment if you’re having issues, and I’ll update this post as we discover configuration problems and find workarounds.
1 year ago
3 notes

rahulrockystuff liked this

bencochran liked this

andymatuschak liked this

cbowns posted this
About

Silicon Information

Silicon Information

Silicon is a gray , brittle, tetravalent, nonmetallic element occurring abundantly in nature. Next to Oxygen it is the chief elementary constituent of the earth's crust. The symbol for Silicon is Si it's atomic number is 14 and it's atomic mass is 28.086. This element is almost always found in various compounds both in nature and in industry, in nature you find it in quartz, jasper, agate, flint, common beach sand, sandstone and many other common rocks and materials. In industry we find it as the main component in the most common building materials such as cement, bricks, glass and others. It is also used in many polymers such as Silicone rubber as well as thousands of other uses including heat resisting resins, lubricants, water resistant films etc., etc.Silicon as a Semiconductor: Perhaps one of the most important uses for Silicon in the second half of the twentieth century and beyond, is it's ability to conduct electricity in a very controlled manner. Relative to how many impurities or dopants (Boron, Phosphorus, Arsenic, Antimony, etc.) are placed into it's crystal structure. Simply put, the more dopant in the crystal lattice of Silicon the more it will conduct electricity. In theory pure monocrystalline Silicon will not conduct electricity very well at all, the beauty of Silicon is that it can be made to take on dopants precisely and after this doping it will normally remain stable under many adverse conditions. Thus making the Silicon wafer an ideal Palette or surface for the construction of today's and tomorrow's most advanced semiconductor devices. The making of a Silicon wafer: With all this talk of sand and glass it may begin to over simplify a very complex process. The process of growing Ingots of monocrystalline Silicon with a uniform and controlled dopant and oxygen content, and then to take these Ingots and grind, slice and polish them into the final Prime wafers mostly free of defects that major Fab's will use to build advanced semiconductor devices on, is nothing short of a monumental task. At Process Specialties we don't think that The Silicon Manufacturers will ever get enough credit for the work and the achievements they have made in helping to forward this industry to the place it is today.

Raw Material: Silicon is the raw material of course, the crucible at the right is filled with pure Polysilicon chips. These chunks of Poly have been made from sand by means of a complex reduction and purification process using Trichlorosilane and Hydrogen. Then the Polysilicon is further distilled and reduced and finally deposited on heated Titanium or Tantalum tubes. After further processing it becomes the material you see at the RIGHT or it may be in a granular form. The Poly is in a quartz container called a crucible and this material is now ready to go on to the next processing step in the manufacturing of a high quality Silicon wafer. This part of the manufacturing process is carried out by large Silicon manufacturers or the material is sometimes purchased by Silicon companies from other vendors.

...Crystal Pulling is the next step in the Manufacturing of a Silicon wafer. In this process the Polysilicon chunks or granules are loaded into the Quartz crucible of the Crystal pulling furnace along with a small amount of either Boron, Phosphorus, Arsenic or Antimony dopant. The Polysilicon is then melted at a process temperature of 1400° C in a high purity Argon gas ambient. Once the proper "melt " is achieved a "seed" of single crystal Silicon is lowered into the melt. Then the temperature is adjusted and the seed is rotated as it is slowly pulled out of the molten Silicon. The surface tension between the seed and the molten Silicon causes a small amount to rise with the seed, as it is pulled and cooled into a perfect monocystalline ingot with the same crystal orientation as the seed. The cut-away view at the LEFT is of the lower portion of the crystal pulling furnace, these machines can stand 12-15 feet high and are quite complex in nature. These furnaces also must be very stable and vibration free since the process takes hours and the slightest jarring of the furnace can break the Ingot from the seed.

At the right is an actual picture of a "Seed" and Ingot inside of a crystal pulling furnace.

...Next the finished Ingot is ground to a rough size diameter (a little larger than a finished wafer) and it is either notched or flatted along it's length to indicate the orientation of the Ingot. This is also a point when many inspections are made on the ingot to catch any major flaws or problems with resistivity etc. The 200mm and 150mm ingots at the LEFT are freshly pulled and have not yet been ground, notched or flatted.

.Slicing: In the next step the Ingots are sliced into wafers using a diamond ID saw or other type of saw. Deionized water is used to cool the blade on this ID (inside diameter) saw. The saw at the RIGHT is slicing 150mm wafers and if you look closely you can see the major flat of the wafer on the left.

.Lapping is next, in this step the Ingots have now become rough cut Silicon wafers with saw marks and other defects on both sides of the wafer. Also at this point the wafer is much thicker than it will be when it is finished. Lapping the wafers accomplishes several things, it removes saw marks and surface defects from the front and backside of the wafers, it thins the wafer and relieves a lot of the stress accumulated in the wafer from the sawing process. Both before and after the lapping process many in-process checks will be done on the Silicon wafers and more fall-out will occur (good news for the people that need coin roll for test wafers). At the LEFT you can see a drawing of the "business end" of a typical lapping machine. After lapping the wafers go thru several cleaning /etching steps using sodium hydroxide or acetic and nitric acids to remove microscopic cracks and surface damage caused by the lapping process, this is followed by followed by deionized water rinses.

Edge grinding or rounding is an important part of the wafer manufacturing process, it is normally done before or after lapping, this rounding of the edge of the wafer is very important! If it is not done the wafers will be more susceptible to breakage in the remaining steps of the wafer manufacturing process and the device manufacturing processes to come. If you look at the edge of a finished wafer you will see the edge rounding even in the notch area of 200mm and 300mm wafers. On the best Prime wafers the edges are also highly polished, this can improve cleaning results on wafers and reduce breakage up to 400%. Process Specialties has seen a notable yield differential between poorly and perfectly edge rounded material.

.Polishing is the next step in the wafer manufacturing process. Most Prime wafers go through 2-3 polishing steps using progressively finer slurry (slurry is the polishing compound). The polishing is normally done on the frontside of the wafer, but sometimes it is done on both sides. Polishing is done on huge precision machines that are capable of extraordinary tolerances. The systems at the RIGHT have 59" wheels and are made by Speedfam Inc. Prior to final polishing some wafers may receive what is called backside damage, two examples would be bead blast and brush damage. The wafers may also receive a backside coating of Polysilicon, all these treatments are done to the backsides of the wafer for the purpose of Gettering defects(later in the device manufacturing process these backside treatments  will draw defects in the Silicon towards the backside of the wafer and away from the frontside where the devices are being built, this is called Gettering). After polishing the wafers are rinsed in DI water and scrubbed to remove any residual slurry compounds from the wafer.

Final Cleaning: The next step in the process after polishing is a rather intense regimen of cleans and scrubs to remove trace metals, residues and particles from the surface(s) of the finished Silicon wafers. Normally most wafer manufacturers use a final cleaning method developed by RCA in the 1970's the first part of this clean is called SC1 and consists of Ammonium Hydroxide followed by a dilute Hydrofluoric acid clean followed by a DI water Rinse. Next the SC2 clean which consists of Hydrochloric acid and Hydrogen peroxide followed by a DI water rinse. Many companies modify these cleans to make them even more effective. After all this cleaning and rinsing the finished wafers will now go through a front and backside scrub to remove even the smallest particles.

.Final sort and inspection: This is one of the last steps in the long wafer manufacturing process. It is here that the wafers either meet or fail the specifications the customers (IC manufacturers) have asked for. There are many specifications the final prime wafers must meet according to agreements made between the customers and the Silicon manufacturer. We will talk about these specifications in a generalized form here, some specifications are tighter, some more relaxed depending on the end user and their requirements. Not including particles and other visual measurements most final sorting of wafers occurs on a automated system like the ADE 9650 pictured at the RIGHT. These compact systems can measure many different parametersincluding Thickness, Bow-Warp, TTV, Site & Global flatness, Type and Resistivity. Particles, Scratches and haze are normally measured on a system like a Tencor Surfscan 6420 pictured at the LEFT. These systems can sort for pits in the Silicon, tiny scratches and the smallest particles on the best most highly polished Prime wafers. Note: Even the newest particle counters need regular calibration using a traceable particle standard. At the most enhanced viewing levels, the surface of many films (like Silicon Nitride) can be rough or have other defects & features that can show up as particles on a un-calibrated system, even when there is No particulate present.

P-Type wafers are Prime or Test wafers that have Boron as the main dopant. A P+ wafer is heavily doped with Boron <1 Ohm/cm2 (normally will be used as an Epi substrate). A P- wafer is lightly doped with Boron and usually has a resistivity >1 Ohm/cm2 an example would be 5-10 Ohm/cm2. P-type wafers can have a 100 orientation (most common) or a 111 orientation (the 111 substrate is normally used for Bi-polar devices). Note: We do not recommend using 111 material for R & D Etch or lithography purposes Because it breaks into pie shaped pieces when it is cleaved and it is therefore no good for SEM. analysis.

N-Type wafers are Prime or Test wafers that have Phosphorus, Antimony or Arsenic as the main dopant. A N+ wafer is heavily doped <1 Ohm/cm2 (and very rare). The most common N-Type wafer is doped with either Antimony or Phosphorus and has a resistivity >1 Ohm/cm2 (normal for device building would be 2-10 Ohm/cm2). The later being used most commonly for advanced CMOS device fabrication where implanted P-Wells are used.

.Total Thickness Variation is an important measurement done on Prime wafers at final inspection. It is done on a flatness checking machine like the ADE system pictured above. TTV represents the difference between the minimum and maximum thickness measured on the wafer. A typical number on a good 8" Prime wafer would be < 15 um (of course as you read this the art of wafer polishing is advancing and better and better TTV's are being reported). We have seen "test" wafers with high TTV's and a high Taper reading that look like a wedge!

.Site TIR or Total Indicator Reading is a site by site measurement of flatness of a Prime wafer. There are a few ways of taking this measurement Best fit, site Best fit, etc. If you are interested in great optical submicron Photolithography there is only one the Silicon guys will admit is the best way of measuring flatness. That way is Site flatness-Backside referenced measuring a 20x20mm or larger site and each one of these sites must meet <.3 um flatness across each site. Now thats a wafer you can resolve .25-.5 um geometries on, and if it meets this specification on 90-100% of the sites on the wafer you have got a really Great wafer! We are not even going to discuss Global flatness on this page because we think that parameter alone without Site TIR is next to worthless!

Bow & Warp are two important specifications in determining the quality of a wafer at final inspection. First let's discuss Bow, this is the measure of how concave or convex the deformation of the median surface of the wafer at the center point, independent of any thickness variations.In this measurement the wafer is in an unclamped state on the chuck of the measurement system a normal or good Bow number on an 8" Prime wafer would be < 30 um. The easy way to visualize Bow is if you think of the wafer as a bowl turned either upside down or rightside up on a flat surface (convex or concave). Next let's talk about Warp, this measument is also made in an unclamped state. Warp is the difference between the maximum and minimum deviations of the median surface relative to the backside reference plane. Now thats a mouthfull, to simplify things think of warp as the deformation of a wafer kind of like a potato chip, thats the easiest way to explain it. A good Warp number on an 8" wafer would be <20 um.

.Resistivity is very important, if you are trying to make good devices or grow uniform Thermal Oxides. The more uniform the resistivity across the wafer and across the cassette of 25, the more uniform the Thermal Oxide you can grow. Understand that how uniform the resistivity of your start material is directly related to how your Oxide will grow. Most engineers know that Thermal Oxide grows faster in areas of low resistivity (more Dopant) and slower in areas of High resistivity (less dopant) To simplify things think of dopant as fertilizer on your lawn, wherever there is more fertilizer, the grass always grows faster... Right? Thermal Oxide growth works the same way! If the dopant uniformity of the start wafer is good you can expect a good Thermal Oxide. Of course that transforms into terrific gate Oxides and more stable and reliable devices. Ingots can have resistivity problems as well as some wafers. We have seen resistivity changes across a finished wafer of 2-4% and on Epitaxial wafers we have seen radial resistivity vary across a epitaxial wafer with a median resistance of 3 -20 Ohm/cm2 up to 15% across the wafer! As you can see epitaxial wafers are not always a good choice for uniform thermal Oxides.

Defects in Silicon are one of the principle causes for rejection of Silicon wafers both by the large Silicon manufacturers and the IC manufacturers. A lot of the time if you buy wafers from a Silicon Vendor and not a manufacturer they might be called "Prime wafers", but chances are they have some faults. Most likely they have been rejected by some Fab or the Wafer manufacture for one thing or another, and if you can find out what for, you are way ahead of the game. Remember though this is not a bad thing, most of these wafers are perfectly fine for most tool R & D uses and they are able to be sold for reasonable prices. True prime wafers that meet all the specs and are suitable for device manufacture are very expensive! So smile when you get a good price on Prime and you get a good wafer with very few defects. There are many defects associated with Silicon wafers and most are caught at the Silicon Manufacturer, some are not. Wafer defects range from pits in the Silicon surface and tiny scratches, to things that are Hidden from view, buried below the Silicon surface like the picture at the RIGHT of Copper Precipitates (a common defect). Found just below the Silicon surface by means of a SIRTL etch for 60 sec. This defect exhibits a crows foot like appearance and would cause a bad Gate Oxide over this region, causing a failed device(s). If this defect was under a few points on your 49 point Thermal Oxide Measurement map, you would definitely see non-uniform Oxides in these areas (Thermal Oxide growth can accelerate or decelerate over defects in the Silicon). There are many Hidden defects in Silicon wafers and to date no one has made a perfect one. Perhaps someday when they grow ingots on the Space station we will get Silicon with zero defects but until then, the major Silicon manufacturers back on Earth are turning out some incredible Silicon Wafers!

. Epitaxy: The growth of a single crystal Silicon layer on the front side of the wafer (polished side) is something Silicon manufactures do all the time. This is a very difficult process and is prone to many defects. It is normally part of the Silicon manufacturing process, but it is also done at the IC manufacturing facilities. For this reason we will discuss this CVD film in more detail in another article.

If you read your way down this page, you know a lot more about Silicon wafer manufacturing than most people that work in the Silicon Valley! If you scrolled down the page looking at the pictures maybe you're interested enough now to go back up to the top of the page and read your way down this time, and you might learn something too!

.If you would like more information on Silicon wafer processing, talk to a Silicon manufacturer or give one of our process engineers a call (800) 533-8820 or e-mail us at Process Specialties Inc.

© 1997 Process Specialties Inc.

Deployment Management Tools: Chef vs. Puppet vs. Ansible vs. SaltStack vs. Fabric | Takipi Blog

Deployment Management Tools: Chef vs. Puppet vs. Ansible vs. SaltStack vs. Fabric | Takipi Blog: What are the�pros and cons of Chef, Puppet, Ansible, SaltStack and Fabric?

What are the pros and cons of Chef, Puppet, Ansible, SaltStack and Fabric?

Working in production today often means continuous deployments and an environment distributed all over the world. When your infrastructure is decentralized and cloud-based and you’re dealing with frequent deployments of largely identical services across largely identical servers, having a way to automate the configuration and maintenance of everything is a large boon. Deployment management tools and configuration management tools are designed for this purpose. They enable you to use recipes, playbooks, templates, or whatever terminology to simplify automation and orchestration across your environment to provide a standard, consistent deployment.

There are several considerations to keep in mind when choosing a tool in this space. One is the model for the tool. Some require a master-client model, which uses a centralized control point to communicate to distributed machines, while others can or do operate on a more local level. Another consideration is the makeup of your environment. Some tools are written in different languages and support for particular OSs or setups can vary. Making sure your tool of choice will mesh well with your environment and the particular skills of your team can save you a lot of headaches here.


Follow
OverOps ✔ @overopshq
New Post: Deployment Management Tools: Chef vs. Puppet vs. Ansible vs. SaltStack vs. Fabric http://bit.ly/1IMRFHh pic.twitter.com/SYbttcycYI
10:01 PM - 5 Aug 2015
29 29 Retweets 15 15 likes
1. Ansible

1
Ansible is an open source tool used to deploy applications to remote nodes and provision servers in a repeatable way. It gives you a common framework for pushing multi-tier applications and application artifacts using a push model setup, although you can set it up as master-client if you’d like. Ansible is built on playbooks that you can apply to an extensive variety of systems for deploying your app.

1a

The Ansible Tower dashboard

When to use it: If getting up and running quickly and easily is important to you and you don’t want to install agents on remote nodes or managed servers, consider Ansible. It’s good if your need or focus is more on the system administrator side. Ansible is focused on being streamlined and fast, so if those are key concerns for you, give it a shot.

Price: Free open source version, with paid plans for Ansible Tower starting at $5,000 per year (which gives you up to 100 nodes).

Pros:

SSH-based, so it doesn’t require installing any agents on remote nodes.
Easy learning curve thanks to the use of YAML.
Playbook structure is simple and clearly structured.
Has a variable registration feature that enables tasks to register variables for later tasks
Much more streamlined code base than some other tools
Cons:

Less powerful than tools based in other programming languages.
Does its logic through its DSL, which means checking in on the documentation frequently until you learn it
Variable registration is required for even basic functionality, which can make easier tasks more complicated
Introspection is poor. Difficult to see the values of variables within the playbooks
No consistency between formats of input, output, and config files
Struggles with performance speed at times.
View video

2. Chef

2
Chef is an open source tool for configuration management, focused on the developer side for its user base. Chef operates as a master-client model, with a separate workstation needed to control the master. It’s based in Ruby, with pure Ruby used for most elements you write. The Chef design is transparent and based on following the instructions it’s given, which means that you’ll have to make sure your instructions are clear.

2a

The Chef dashboard

When to use it: Before considering Chef, make sure you’re familiar with Git, as it’s required for configuration, and Ruby, as you’ll have to be writing in it. Chef is good for development-focused teams and environments. It’s good for enterprises looking for a more mature solution for a heterogeneous environment.

Price: Free open source version, standard and premium plans priced on a per node per month basis that can get down to $6/node/month or $6.75/node/month respectively at high volume.

Pros:

Rich collection of modules and configuration recipes.
Code-driven approach gives you more control and flexibility over your configurations.
Being centered around Git gives it strong version control capabilities.
‘Knife’ tool (which uses SSH for deploying agents from workstation) eases installation burdens.
Cons:

Learning curve is steep if you’re not already familiar with Ruby and procedural coding.
It’s not a simple tool, which can lead to large code bases and complicated environments.
Doesn’t support push functionality.
View video

Find the Crap in Your Java App

Show me how >> Fred
3. Fabric

3
Fabric is a Python-based tool for streamlining SSH in application deployments. Its primary usage is for running tasks across multiple remote systems, but it can also be extended with plugins to provide more advanced functionality. Fabric will configure your system, do system/server administration, and automate the deployment of your app.

When to use it: If you’re just starting out in the deployment automation space, Fabric is a good beginning point. It helps if your environment involves at least a little bit of Python.

Price: Free

Pros:

Good at deploying apps written in any language. It doesn’t depend on system architecture, but rather OS and package manager.
Simpler and easier to deploy than some other tools in this space
Extensively integrated with SSH for script-based streamlining
Cons:

Fabric is a single point of failure set up (generally the machine you’re running the deploy on)
Uses a push model, so not as well suited for a continuous deployment model as some other tools in this space
While it’s a great tool for deploying apps in most languages, it does require Python to run, so you must have at least a little Python in your environment for Fabric.
View video

4. Puppet

4
Puppet is one of the long standing tools in the full-fledged configuration management space. It’s an open source tool, but given how long it’s been around, it has been well vetted and deployed in some of the biggest and most demanding environments. Puppet is based in Ruby, but uses a customized Domain Scripting Language (DSL) closer to JSON for working within it. It runs as a master-client setup and uses a model-driven approach. The Puppet code design works as a list of dependencies, which can make things easier or more confusing, depending on your setup.

4a

The Puppet Enterprise dashboard

When to use it: Puppet is a good choice if stability and maturity are key factors for you. It’s good for large enterprises with a heterogeneous environment and range of skills on the DevOps team.

Price: Puppet comes in a free open source version or a paid commercial enterprise version that runs $112 per node per year, with volume discounts.

Pros:

Well-established support community through Puppet Labs.
It has the most mature interface and runs on nearly every OS.
Simple installation and initial setup.
Most complete Web UI in this space.
Strong reporting capabilities.
Cons:

For more advanced tasks, you will need to use the CLI, which is Ruby-based (meaning you’ll have to understand Ruby).
Support for pure-Ruby versions (rather than those using Puppet’s customized DSL) is being scaled back.
Because of the DSL and a design that does not focus on simplicity, the Puppet code base can grow large, unwieldy, and hard to pick up for new people in your organization at higher scale.
Model-driven approach means less control compared to code-driven approaches.
View video

5. Saltstack

Saltstack
SaltStack (or Salt) is a CLI-based tool that can be set up as a master-client model or a non-centralized model. Based in Python, Salt offers a push method and an SSH method of communication with clients. Salt allows for grouping of clients and configuration templates to simplify the control of the environment.

When to use it: Salt is a good choice if scalability and resiliency are a big concern. It’s good for system administrators thanks to its usability.

Price: Free open source version, and a SaltStack Enterprise version that is based on an annual per node subscription basis. Specific pricing is not listed on their site (just a “Contact us” link), but others have reported a $150 per node per year starting point.

Pros:

Straightforward organization and usage once you’re past the setup phase.
Their DSL is feature-rich and isn’t required for logic and states.
Input, output, and configs are very consistent – all YAML.
Introspection is very good. It’s easy to see what’s happening within Salt.
Strong community.
High scalability and resiliency in the master model with minions and hierarchical tiers.
Cons:

Difficult to set up and to pick up for new users.
Documentation is challenging to understand at the introductory level.
Web UI is newer and less complete than other tool’s Web UIs in the space.
Not great support for non-Linux OSs.
View video

Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack

Which configuration management or deployment automation tool you use will depend on your needs and preferences for your environment. Chef and Puppet are some of the older, more established options, making them good for larger enterprises and environments that value maturity and stability over simplicity. Ansible and SaltStack are good options for those looking for fast and simple solutions while working in environments that don’t need support for quirky features or lots of OSs. Fabric is a good tool for smaller environments and those looking for a more low lift and entry level solution.

Background Modes Tutorial: Getting Started

Background Modes Tutorial: Getting Started: Background Modes Tutorial: Getting Started
Skip the reading — click here for our massive collection of video courses

close


Search

Tutorials
Swift
iOS
Android
macOS
Apple Game Frameworks
Unity
Articles
Archive
Videos
Home
Courses
Screencasts
Podcast
Forums
Store

Background Modes Tutorial: Getting Started

Chris Wagner on October 24, 2016



Learn how to make your app do stuff even when it is no longer active.
Learn how to make your app do stuff even when it is no longer active.

Update note: This tutorial was updated to iOS 10 and Swift 3 by Chris Wagner. This marks the third revision; original post by Gustavo Ambrozio and second revision by Ray Fix.

Way back in 2010 with iOS 4, Apple introduced multitasking.

Developers and users alike are often confused as to what the iOS multitasking system allows. Apple has restrictions in place for the use of background operations in an effort to improve user experience and extend battery life. Your app is only allowed to keep running in the background in very specific cases. For example, these include playing audio, getting location updates, or fetching the latest content from a server.

If your task does not fall into these categories backgrounding may not be for you. You may even find yourself with an App Store rejection if you try to cheat the system by using background modes outside the realm of their purposes, so consider yourself warned! :]

Getting Started

Before digging into the project, here’s a quick overview of the basic background modes available in iOS. In Xcode 8, you can see the list by pulling up the Capabilities tab of your app target. It looks like this:

background modes

To get to the background modes capability list you (1) select the project from the Project Navigator, (2) select the app target, (3) select the Capabilities tab, and (4) turn the Background Modes switch on.

In this background modes tutorial you will investigate four ways of doing background processing.

Play audio: the app can continue playing and/or recording audio in the background.
Receive location updates: the app can continue to get callbacks as the device’s location changes.
Perform finite-length tasks: the generic “whatever” case, where the app can run arbitrary code for a limited amount of time.
Background Fetch: Get updates to the latest content scheduled by iOS.
If you are only interested in one or several of these modes, feel free to skip around!

To get started download the starter project. You’ll find the user interface and some of the logic that is not directly applicable to the topic has been provided for you.

Before you can run the project you must set your development team, as shown here:

background modes

Run the sample project to get a feel for it. There are 4 tabs; one to cover each mode:

background modes

Note: For the full effect, you should follow along on a real device. In my experience, if you forget a configuration setting, the app might appear to run fine in the background on the Simulator. However, when you switch to a real device, it doesn’t work at all.

Playing Audio

First up, background audio.

There are several ways to play audio on iOS and most of them require implementing callbacks to provide more audio data to play.

If you want to play audio from streaming data, you can start a network connection, and the connection callbacks provide continuous audio data.

When you activate the audio background mode, iOS will continue these callbacks even if your app is not the current active app. That’s right – the audio background mode is virtually automatic. You just have to activate it and provide the infrastructure to handle it appropriately.

In this section you’ll review the audio player in the app, verify that background mode is not working, enable the audio background capability, and demonstrate to yourself that it’s working.

Open AudioViewController.swift and take a look around.

The app makes use of an AVQueuePlayer to queue up songs and play them one after the other. The view controller is observing the player’s currentItem value to provide updates.

The starter project includes audio files from incompetech.com, a favorite royalty-free music website. With credit given, you can use the music for free. So, here you go: all songs are by Kevin MacLeod at incompetech.com. Thanks, Kevin!

When the app is in the active state, the music title label is shown and when in the app is in the background it will print the title to the console. The label text could still update while in the background, but the point here is just to demonstrate that your app continues to receive this callback when your app is in the background.

Note: Check out the Execution States for Apps to learn more about the active state and others.

Build and run, and you should see this:

background modes

Now hit Play and the music will start. Nice!

Test if backgrounding works. While running on an actual device hit the home button and the music will stop. Why? Well, there’s still a very crucial piece missing!

For most background modes (the “Whatever” mode is the exception) you need to enable the capability to indicate that the app wants to run code while in the background.

Back in Xcode, do the following:

Click the project in the Project Navigator;
Click TheBackgrounder target;
Click on the Capabilities tab;
Scroll down to Background Modes and turn the switch on;
Check Audio, AirPlay and Picture in Picture.
background modes

Build and run again. Start the music and hit the home button, and this time you should still hear the music, even though the app is in the background.

You should also see the time updates in your Console output in Xcode, proof that your code is still working even though the app is in the background.

Wow, if you already have an audio player in place, playing audio in the background is easy! Well, that’s one mode down, if you’re following through the entire background modes tutorial – three to go!

Receiving Location Updates

When in location background mode, your app will still receive location delegate messages with the updated location of the user, even when the app is in the background. You can control the accuracy of these location updates and even change that accuracy while backgrounded.

The second tab is for location updates, so open LocationViewController.swift and take a look around. Similarly to the background audio example, the location background mode is very easy to get up and running with if you already have location features working!

In this controller you will find that CLLocationManager runs the show. To receive location information you create and configure a CLLocationManager instance. In this case the app monitors location when an on screen UISwitch is activated. As location updates are received the app draws pins on a map. When the app is in the background, you should see the log of location updates in your console output in Xcode.

An important line to note is the call to requestAlwaysAuthorization() on the CLLocationManager instance. This is a requirement since iOS 8, and brings up a dialog asking for permission to receive locations in the background.

Now that you’re familiar with Background Modes, you don’t need to make the same mistake as before! Check the box for Location updates to let iOS know that your app wants to continue receiving location updates while in the background.

background modes

In addition to checking this box, iOS 8 and above requires that you set a key in your Info.plist explaining to the user why background updates are needed. If you do not include this, location requests will silently fail.

Select the project in Xcode.
Select the Info tab for TheBackgrounder target.
Select an existing row.
Click on the + button to add a new key.
Add the key named Privacy – Location Always Usage Description.
Write a convincing description of why you need to receive location updates in the background.
background modes

Now build and run! Switch to the second tab and flip the switch to ON.

When you do this the first time, you will see the message that you put into your location privacy reason. Tap Allow and go for a walk outside or around your building (try not to get too distracted catching Pokemons). You should start seeing location updates, even on the Simulator.

background modes

After a while, you should see something like this:

background modes

If you background the app, you should see the app updating the location in your console log. Open the app again and you’ll see that the map has all the pins for the locations that were updated while the app was in the background.

If you’re using the Simulator, you can use it to simulate movement, too! Check out the Debug \ Location menu:

background modes

Try setting the location to Freeway Drive and then hit the home button. You should see the console logs printing out your progress as you simulate that drive down a California highway:

App is backgrounded. New location is %@ <+37.33500926,-122.03272188> +/- 5.00m (speed 7.74 mps / course 246.09) @ 9/5/16, 10:20:07 PM Mountain Standard Time
App is backgrounded. New location is %@ <+37.33500926,-122.03272188> +/- 5.00m (speed 7.74 mps / course 246.09) @ 9/5/16, 10:20:07 PM Mountain Standard Time
App is backgrounded. New location is %@ <+37.33500926,-122.03272188> +/- 5.00m (speed 7.74 mps / course 246.09) @ 9/5/16, 10:20:07 PM Mountain Standard Time
Easy peasy, right?! On to the third tab and the third background mode!

Performing Finite-Length Tasks… or, Whatever

The next background mode is officially called Executing a Finite-Length Task in the Background. What a mouthful. Whatever is a bit catchier!

Technically, this is not a background mode at all, as you don’t have to declare that your app uses this mode in Capabilities. Instead, it’s an API that lets you run arbitrary code for a finite amount of time when your app is in the background. Well… whatever!

In the past, this mode was often used to complete an upload or download and a generous (but not guaranteed) 10 minutes was provided to accomplish these tasks. But what if the connection was slow and the process still didn’t finish? It would leave your app in an odd state and you would have to add lots of error handling code to make things work sanely. Because of this, Apple introduced NSURLSession.

Although not a topic of this background modes tutorial, NSURLSession is robust in the face of backgrounding and even device reboots and accomplishes this in a power efficient way. If you are dealing with large downloads, check out our NSURLSession tutorial.

A still very valid use case of the Whatever background mode is to complete some long running task, such as rendering and writing a video to the camera roll.

background modes

But this is just one example. As the code you can run is arbitrary, you can use this API to do pretty much anything: perform lengthy calculations (as in this background modes tutorial), apply filters to images, render a complicated 3D mesh… whatever! Your imagination is the limit, as long as you keep in mind that you only get some time, not unlimited time.

How much time you get after your app gets backgrounded is determined by iOS. There are no guarantees on the time you’re granted, but you can always check backgroundTimeRemaining on UIApplication. This will tell you how much time you have left.

The general, observation-based consensus is that you get three minutes. Again, there are no guarantees and the API documentation doesn’t even give a ballpark number – so don’t rely on this number. You might get 5 minutes or 5 seconds, so your app needs to be prepared for… whatever!

Here’s a common task that every CS student should be familiar with: calculating numbers in the Fibonacci Sequence. The twist here is that you’ll calculate these numbers in the background!

Open WhateverViewController.swift and take a look at what’s there already. As it stands, this view will calculate Fibonacci numbers in sequence and display the result. If you were to suspend the app on an actual device, the calculations would stop and pickup where they were once the app was active again. Your task is to create a background task so that the calculation can keep running until iOS says, ‘No more!’.

You first need to add the following property to WhateverViewController.

var backgroundTask: UIBackgroundTaskIdentifier = UIBackgroundTaskInvalid
This property is used to identify the task request to run in the background.

Next add the following methods to WhateverViewController.

func registerBackgroundTask() {
backgroundTask = UIApplication.shared.beginBackgroundTask { [weak self] in
self?.endBackgroundTask()
}
assert(backgroundTask != UIBackgroundTaskInvalid)
}

func endBackgroundTask() {
print("Background task ended.")
UIApplication.shared.endBackgroundTask(backgroundTask)
backgroundTask = UIBackgroundTaskInvalid
}
registerBackgroundTask() tells iOS that you need more time to complete whatever it is you’re doing in case the app is backgrounded. After this call, if your app is backgrounded it will still get CPU time until you call endBackgroundTask().

Well, almost. If you don’t call endBackgroundTask() after a period of time in the background, iOS will call the closure defined when you called beginBackgroundTask(expirationHandler:) to give you a chance to stop executing code. So it’s a very good idea to then call endBackgroundTask() to tell the OS that you’re done. If you don’t do this and continue to execute code after this block is called, your app will be terminated!

Now for the important part, you need to update didTapPlayPause(_:) to register the background task and end it. There are two comments in this method where you will add some code.

Call registerBackgroundTask() below the “register background task” comment.

// register background task
registerBackgroundTask()
registerBackgroundTask() is now called when calculations begin so you can continue calculating numbers in the background.

Now add the following block below the “end background task” comment.

// end background task
if backgroundTask != UIBackgroundTaskInvalid {
endBackgroundTask()
}
Now when calculations are stopped by the user endBackgroundTask() is called to indicate to iOS that you don’t need any extra CPU time.

It is important that you call endBackgroundTask() for every time you call beginBackgroundTask(expirationHandler:). If you call beginBackgroundTaskWithExpirationHandler(_:) twice and only call endBackgroundTask() for one of the tasks, you’re still going to get CPU time until you call endBackgroundTask() a second time with the value of the second background task. This is also why you needed backgroundTask.

Now update the calculateNextNumber() method to behave differently based on the application’s state.

Replace the final line, resultsLabel.text = resultsMessage, in the method with the following:

switch UIApplication.shared.applicationState {
case .active:
resultsLabel.text = resultsMessage
case .background:
print("App is backgrounded. Next number = \(resultsMessage)")
print("Background time remaining = \(UIApplication.shared.backgroundTimeRemaining) seconds")
case .inactive:
break
}
The label will only be updated when the application is active. When the application is backgrounded a message will be printed to the console instead, stating what the new result is and how much background time is remaining.

Build and run, then switch to the third tab.

background modes

Tap Play and you should see the app calculating the values. Now hit the home button and watch the output in Xcode’s console. You should see the app still updating the numbers while the time remaining goes down.

In most cases, this time will start with 180 (180 seconds = 3 minutes) and go down to 5 seconds. If you wait for the time to expire when you reach 5 seconds (could be another value depending on your specific conditions), the expiration block will be invoked and your app should stop outputting anything. Then if you go back to the app, the timer should start firing again and the whole madness will continue.

There’s only one bug in this code. Suppose you background the app and wait until the allotted time expires. In this case, your app will call the expiration handler and invoke endBackgroundTask(), thus ending the need for background time.

If you then return to the app, the timer will continue to fire. But if you leave the app again, you’ll get no background time at all. Why? Because nowhere between the expiration and returning to the background did the app call beginBackgroundTaskWithExpirationHandler(_:).

How can you solve this? There are a number of ways to go about it and one of them is to use a state change notification.

You can see all the details on how to respond to state change in Apple’s documentation for App States for Apps.

Time to fix the bug. First, add a new method named reinstateBackgroundTask().

func reinstateBackgroundTask() {
if updateTimer != nil && (backgroundTask == UIBackgroundTaskInvalid) {
registerBackgroundTask()
}
}
You only need to reinstate if there is a timer running and the background task is invalid. Breaking your code into smaller utility functions that do one thing is paying off. In this case you simply need to call registerBackgroundTask().

Now override viewDidLoad() and subscribe to UIApplicationDidBecomeActiveNotification by adding the following:

override func viewDidLoad() {
super.viewDidLoad()
NotificationCenter.default.addObserver(self, selector: #selector(reinstateBackgroundTask), name: NSNotification.Name.UIApplicationDidBecomeActive, object: nil)
}
This designates your new method reinstateBackgroundTask() to be called whenever the application becomes active.

Whenever you subscribe to a notification you should also think about where to unsubscribe. Use deinit to do this. Add the following:

deinit {
NotificationCenter.default.removeObserver(self)
}
And there you have it, you can now do whatever you want, at least for as long as iOS says that it is okay.

On to the final topic for this background modes tutorial: Background Fetching.

Background Fetch

Background fetch is a mode introduced in iOS 7 that lets your app appear always up-to-date with the latest information while minimizing the impact on battery. Suppose, for example, you were implementing a news feed in your app. Prior to background fetch, you might do this by getting new data in viewWillAppear(_:).

The problem with this solution is that your user is looking at the old data for at least several seconds until the new data comes in. Wouldn’t it be better if right when they opened your app the new data was magically there? This is what background fetch gives you.

When enabled, the system uses usage patterns to determine when to best fire off a background fetch. For example, if your user opens the app at 9 AM each morning, it is likely that a background fetch will be scheduled sometime before that time. The system decides the best time to issue a background fetch and for this reason you should not use it to do critical updates.

In order to implement background fetch there are three things you must do:

Check the box Background fetch in the Background Modes of your app’s Capabilities.
Use setMinimumBackgroundFetchInterval(_:) to set a time interval appropriate for your app.
Implement application(_:performFetchWithCompletionHandler:) in your app delegate to handle the background fetch.
As the name implies, background fetch normally involves fetching information from an external source like a network service. For the purposes of this background modes tutorial, you won’t use the network but just fetch the current time. This simplification will let you understand everything required to perform a background fetch and test it without worrying about an external service.

In contrast to finite-length tasks, you only have seconds to operate when doing a background fetch – the consensus figure is a maximum of 30 seconds, but shorter is better. If you need to download large resources as part of the fetch, this is where you need to use NSURLSession‘s background transfer service.

Time to get started. First, open FetchViewController.swift and take a look at what this does, there’s not much to it.

The fetch(_:) method is a simplified replacement of what you might actually do to fetch some data from an external source (such as a JSON or XML RESTful service). Since it might take several seconds to fetch and parse the data, you pass a completion handler that gets called when the process is done. You will see why this is important a little later.

updateUI() formats the time and shows it. The guard statement around updateLabel is to ensure that the view has actually been loaded. time is an optional type so if it is not set, it shows the message “Not updated yet”.

When the view is first loaded (in viewDidLoad()) you don’t fetch, but go straight to updateUI() which means the message “Not yet updated” will appear first. Finally, when the Update button is tapped it performs a fetch and as a completion updates the UI.

The view controller is working. There’s nothing you need to do to it.

background modes

However, background fetching is not enabled.

The first step to enabling background fetching is to check Background fetch in the Capabilities tab of your app. By now this should be old hat. Go ahead and do this.

background modes

Next, open AppDelegate.swift add the following to application(_:didFinishLaunchingWithOptions:):

UIApplication.shared.setMinimumBackgroundFetchInterval(UIApplicationBackgroundFetchIntervalMinimum)
This requests background fetches by setting the minimum background fetch interval. The default interval is UIApplicationBackgroundFetchIntervalNever, which you might want to switch back to, if, for example, your user logs out and no longer needs updates. You can also set a specific interval in seconds. The system will wait at least that many seconds before issuing a background fetch.

Be careful not to set the value too small because it may chew through battery unnecessarily as well as hammer your server. In the end the exact timing of the fetch is up to the system but will wait at least this interval before performing it. Generally, UIApplicationBackgroundFetchIntervalMinimum is a good default value to use.

Finally, to enable background fetch you must implement application(_:performFetchWithCompletionHandler:). Add that now to AppDelegate:

// Support for background fetch
func application(_ application: UIApplication, performFetchWithCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
if let tabBarController = window?.rootViewController as? UITabBarController,
let viewControllers = tabBarController.viewControllers
{
for viewController in viewControllers {
if let fetchViewController = viewController as? FetchViewController {
fetchViewController.fetch {
fetchViewController.updateUI()
completionHandler(.newData)
}
}
}
}
}
First you need to get the FetchViewContoller. Next, optionally cast since the rootViewController is not necessarily a UITabBarController in every app, although it is in this app so it will never fail.

Next, you loop though all of the view controllers in the tab bar controller and find the one that successfully casts to FetchViewController. In this app you know it is the last view controller so you could hard-code it, but looping makes it a little more robust in case you decide to add or remove a tab later.

Finally you call fetch(_:). When it completes, you update the UI and then call the completionHandler that was passed in as a parameter of the function. It is important that you call this completion handler at the end of the operation. You specify what happened during the fetch as the first parameter. Possible values are .newData, .noData, or .failed.

For simplicity, the tutorial always specifies .newData since getting the time will never fail and is always different than the last call. iOS can then use this value to better time the background fetches. The system knows at this point to take a snapshot of the app so it can present it in the card view of the app switcher. And that is all there is to it.

Note: Rather than passing the completion closure along, it can be tempting to save it away in a property variable and call that when your fetch completes. Don’t do this. If you get multiple calls to application(_:performFetchWithCompletionHandler:), the previous handler will get overwritten and never called. It is better to pass the handler through and call it as it will make this kind of programming error impossible.

Testing Background Fetch

One way to test background fetch is to sit around and wait for the system to decide to do it. That would require a lot of sitting. Fortunately, Xcode gives a way to simulate a background fetch. There are two scenarios that you need to test. One is when your app is in the background, and the other when your app is coming back from being suspended. The first way is the easiest and is just a menu selection.

Start the app on an actual device (not a simulator);
Go to the Fetch tab
Notice the message is “Not yet updated”
From the Debug menu in Xcode, select Simulate Background Fetch;
background modes
The app will be sent to the background and Xcode’s debugger will trap. Instruct the debugger to continue
background modes
Reopen the app
Notice that the time is updated!.
The other way you should test background fetch is to do it as a resume from suspension. There is a launch option that lets you launch your app directly into suspension. Since you might want to test this semi-often it is best to make a new Scheme with that option always set. Xcode makes this easy.

First select the Manage Schemes option.

background modes

background modes

Next, select the only scheme in the list, and then click on the gear icon and select Duplicate.

background modes

Lastly, rename your scheme to something reasonable, like, “Background Fetch” and check the checkbox to Launch due to a background fetch event.

background modes

Run your app with this scheme. You will notice that the app never actually opens but is launched into a suspended state. Now manually launch it and go to the Fetch tab. You should see that there is an updated time when you launched the app instead of “Not yet updated”.

Using background fetch effectively lets your users to seamlessly get the latest content.

Where to Go From Here?

You can download the fully finished sample project here.

If you want to read Apple’s documentation on what we covered here for background modes, the best place to start is in Background Execution. This documentation explains all background modes and has links to the appropriate section of the documentation for each one.

A particularly interesting section of this document is the one that talks about being a responsible background app. There are some details that might or might not relate to your app here that you should know before releasing an app that runs in the background.

Finally, be sure to check out NSURLSession if you plan on doing large network transfers in the background.

We hope you enjoyed this tutorial on background modes, and if you have any questions or comments, please join the forum discussion below!

Team

Each tutorial at www.raywenderlich.com is created by a team of dedicated developers so that it meets our high quality standards. The team members who worked on this tutorial are:


Author
Chris Wagner

Tech Editor
Adrian Strahan

Final Pass Editor
Andy Obusek

Team Lead
Mic Pringle





Chris Wagner
Chris Wagner currently works as the lead iOS developer at Infusionsoft and started “programming” by playing with QBASIC and the Lego Mindstorms kit (thanks Dad). The next big thing was the web, as an avid gamer for many years (Rogue Spear, Counter-Strike, WOW) he continued to feed his passion for software development by building web sites for his gaming clan and others. After graduating with a Computer Systems Engineering degree from ASU he worked as a Java web app developer before moving on to leading multiple iOS development teams.

Follow Chris Wagner on Twitter

​
Other Items of Interest


Save time.
Learn more with our video courses.

Get Started!
raywenderlich.com Weekly


Sign up to receive the latest tutorials from raywenderlich.com each week, and receive a free epic-length tutorial as a bonus!


Your full name

Your best email
Sign Up!
Our Books











Our Team

Video Team




... 19 total!

Swift Team




... 15 total!

iOS Team




... 27 total!

Android Team




... 15 total!

macOS Team




... 9 total!

Apple Game Frameworks Team




... 10 total!

Unity Team




... 11 total!

Articles Team




... 11 total!

Resident Authors Team




... 14 total!

Write For Us
RWDevCon
FAQ
Advertise
Contact
12k+ Facebook likes
57k+ Twitter followers

Screencasts & Video Tutorials Join over 4,000 subscribers!
Keep your Swift & iOS skills up-to-date via hands-on tutorials — in video form! The largest collection of Swift & iOS video tutorials anywhere.

Learn more
Ray Wenderlich Weekly Development Newsletter
Join 70,000+ Developers raywenderlich.com weekly
Sign up to receive the latest tutorials from raywenderlich.com each week, and receive a free epic-length tutorial as a bonus!


EMAIL
Sign up

© 2016 Razeware LLC. All rights reserved.

1

CN2线路介绍及CN2选购注意事项，CN2 VPS商家推荐 | 古博

CN2线路介绍及CN2选购注意事项，CN2 VPS商家推荐 | 古博



Skip to main content

古博

• 首页
• 精选VPS 
• 域名注册商
• VPS一键安装脚本 
• 关于&留言 

CN2 线路介绍及 CN2 VPS服务商

 2016年10月22日  天毅  VPS

对于电信用户来说，国外的VPS的选择是简单而痛苦的，因为除了CN2线路接入的机房，其它线路接入的VPS都会出现丢包率高，绕道等情况的出现，导致VPS访问速度慢，甚至近乎于不可用的状态。接下来就给大家简单介绍一下CN2线路，选购注意事项及一些CN2接入的VPS提供商。

CN2线路介绍

CN2全称为中国电信下一代承载网，英文Chinatelecom Next Carrier Network，缩写为CNCN，进一步缩写为CN2。

为什么CN2速度那么快
CN2作为“精品网络项目”被提出来，其技术构造是远远领先于电信原有网络的，极为先进的QOS保证网络的畅通性，具体可参考资料。当然除了先进的技术，其昂贵的价格和对大量网络资源的独占性也是重要的原因，资料。普通家庭宽带用户用不上CN2线路，哪怕加几倍的钱也不一定能用上，而接入CN2线路机房的VPS，价格卖得比其他线路的高很多。用户少，服务器少，分配的独享资源多，这样就能保证绝大多数情况下CN2线路的流畅性。

如果想要寻找接入CN2线路的国外VPS提供商，建议使用“Next Carrier Network”这个关键词，但是其实只要有CN2接入的机房，都会被广为流传，国内分销商涌入，所以大家想要选购，找国人商家提供的产品会好找得多。

怎么判断是不是CN线路

判断VPS是否是CN2有如下三种方法，当中以回程mtr/traceroute方法最可靠：

回程MTR测试方法

• 首先到ip检测网站(ipip.net,ip138.com)，查看自己的ip，比如220.173.118.215(广西电信)
• 然后到服务器上输入命令

  mtr -r 220.173.118.215

• 

  香港CN2对比韩国直连

  然后就能得到像图里一样的测试报告，对比一下右边的图，有一项数据是非常明显的，丢包率！
   0丢包率 ：右图中在骨干网部分也就是最后两跳之前，丢包率为0；而左图中韩国在10，11，13跳的时候丢包率非常高。需要说明的是，某些丢包率为100%的节点一般是禁止ping导致的。
   59.43.xxx.xxx ：这样以59.42开头（C段不详）一般为中国电信CN2骨干网IP地址，具体的可以到ipip.net查验，比如可以查图中的 59.43.123.94

从服务器mtr/traceroute这样测回程是最为可靠的办法，毕竟回程是服务器到我们PC的速度，绝大多数情况下上行（从PC传数据到服务器）比下行（从服务器传数据到PC）的量小得多，对速度的要求相应也会低很多。同理，回程是CN2线路的服务器，一般都是双向CN2.

如果没有购买服务器，只需要找到厂商提供的Looking Glass即可，可以直接在一个网页上看到服务器到任何ip的mtr结果，比如http://jp2.lg.starrydns.com/.

老服务商官方介绍

本站推荐&网上搜索

CN2线路的陷阱

CN2线路本身的优越性是无需置疑的，但是，影响VPS速度的因素绝不只有接入线路本身，商家的服务水平也至关重要。随着国内出国线路（尤其是电信）的愈发拥堵，优质线路需求愈发强烈，商家要面对的压力会更大。但凡连接速度稍微快一点的VPS产品，如果没有合理的技术手段，客户里的SS销售商基本都能将带宽跑满，各种加倍发包软件让同服务器的其它客户跑不上速度。下面给大家总结一下需要注意的地方：

1.  便宜CN2需谨慎 ：很简单，便宜的CN2谁都想要，而且用来卖SS利润高。于是是个人都买，都用来开设代理卖给其他人，由于成本低，就算滥用被处罚的损失也小。最典型的案例就是BudgetVM，几乎在2016年3月19日开放介入CN2线路当天就已经拥堵到瘫痪，坚持没几个月就不得不取消CN2线路的接入，即使这样，到今天速度也还没恢复到正常水平(参考链接)。某种程度来说，高价格是高速度的保证。另外最好的例证就是Softlayer香港（非CN2），当初超大流量+超低价格引得无数人争相购买，现在已经沦落到绕道美国再回国内(参考链接)。CN2就是依靠其定价高才能保持流畅性，低价大量销售的结果必然是挤爆，速度得不到保证。
2.  单向CN2需谨慎 ：单向CN一般都是去程CN2，回程普通电信线路。最为典型的是Hostus家，无数Hostus推介网站竞相宣布Hostus的LA KVM构架VPS接入CN2，我也被忽悠入手了一个，一开始以为路由还没优化完毕速度慢，后来官方客服澄清只有国内使用CN2精品网业务的才会走CN2线路，我用精品网业务了还要你这作甚？！原话：”We have both China Telecom and CN2 now in LAX02. Your ISP will, by default, prefer China Telecom AS4134 routes unless you have an active CN2 subscription within China.”
目前来说，香港CN2线路70～90元一个月，带宽峰值2M～3M或者流量400G/月属于正常范围，低于这个价格长期大量有货的请慎重！.
我直接一步到位购买了香港CN2，美西CN2接入的目前并没有发现可靠商家，所以暂不在此进行讨论推荐。

不推荐CN2服务商

• BudgetVM: 感谢评论中朋友的指正，BudgetVM走的还是CN2但是宽带已经基本占满，速度甚至比不上诸如C3之类的优质美国西海岸线路。建议大家购买前谨慎再谨慎！

香港CN2 商家推荐

1.  星光互联 ：从2016年3月至今本站一直在用的服务器，使用已经超过半年，稳定可靠，大家可以放心入手。众多香港CN2服务商中目前只发现这家是10M峰值（虽然流量相应也小了一点），其他家都是3M，5M峰值。此外他家还有韩国，日本，美国等专为中国优化线路的VPS，点击查看评测套餐促销
2. 其它未实测服务商：VPS仓 http://www.vpscang.com 在“特殊线路”中输入“沙田”即可

Related posts:

1. BudgetVM 25美元/年 洛杉矶国内直连 VPS
2. 韩国高速VPS支持支付宝
3. Hostus 16美元/年 768M 伦敦/美国 VPS
4. 香港CN2 VPS 沙田, 韩国Kdata, 日本东京/大阪VPS
5. Hosthatch香港Softlayer机房VPS

CN2

天毅

Linux/php菜鸟，喜欢修修补补，喜欢分享，喜欢写博客，其实主要是喜欢找速度快的国外空间（剁手癌晚期，买VPS完全停不下来）...

文章导航

 修改php和nginx最大上传/发送值

洛杉矶C3机房,Impactvps, BudgetNode, Virmach, Buyvm等VPS测试 

最新文章

• 低价KVM VPS/Windows VPS推荐
• KVMLA/PZEA 香港沙田CN2评测
• 50vz/50kvm 洛杉矶C3/GlobalFrag
• 蘑菇主机韩国BGP高速VPS
• RFCHOST 香港新力讯大水管/洛杉矶C3
• 更改MySQL/MariaDB数据存储目录
• 2016年圣诞新年值得买VPS推荐

优秀IT站点

• Alternative software
• CDNBee
• Google 网站站长工具帮助
• Jerry Qu的小站
• Xunyu Chemical
• Xunyu Poly Aluminium chloride
• 网站分析在中国

合作站点

• Domain Coupon
• Godaddy Coupon Code
• Namesilo Coupon
• Namesilo优惠码&教程
• Pacifichost coupon code!
• Tsohost Coupon
• Vidahost Coupon

sparkling Theme by Colorlib Powered by WordPress